[Bug 89699] Regression in 10.5.1 causes flickering/artifacting in a particular video game

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

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

--- Comment #6 from andre35822 at yahoo.com ---
(In reply to Michel Dänzer from comment #5)
> (In reply to andre35822 from comment #4)
> > I found this https://wiki.archlinux.org/index.php/Bisecting_bugs essentially
> > do I just follow these steps?
> 
> Yes.

Alright I just, I do not have enough knowledge to follow that tutorial I tried
and I am just failing miserably and I can't understand what I am doing. I
upgraded my system to mesa-git (10.6-devel) and I still have the issue so the
issue IS present on 10.6. Hopefully there is someone at the mesa team that
plays games and can test CSGO on AMD hardware?

-- 
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/20150323/699b9e3c/attachment.html>

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

[Hyungwon Hwang]

Dear Andrej,

On Mon, 23 Mar 2015 10:31:58 +0100
Andrzej Hajda  wrote:

> On 03/20/2015 06:15 AM, Hyungwon Hwang wrote:
> > Dear Andrej,
> >
> > On Thu, 19 Mar 2015 10:32:10 +0100
> > Andrzej Hajda  wrote:
> >
> >> On 03/19/2015 02:18 AM, Hyungwon Hwang wrote:
> >>> Dear Daniel,
> >>>
> >>> On Thu, 19 Mar 2015 01:13:21 +
> >>> Daniel Stone 
> >>> wrote:
> >>>
>  Hi Hyungwon,
> 
>  On 19 March 2015 at 01:02, Hyungwon Hwang
>   wrote:
> >>> +   /*
> >>> +* The input PLL clock for MIPI DSI in Exynos5433
> >>> seems to be fixed
> >>> +* by OSC CLK.
> >>> +*/
> >>> +   fin = 24 * MHZ;
> >> Er, is this always true on other platforms as well? Shouldn't
> >> this be a part of the DeviceTree description?
> > I forgot to change the comment in development. Finally it is
> > found that all exynos mipi dsi's fin is OSC clk which is 24
> > MHz. So I will remove the comment, but remain the code as it is.
>  Fair enough. Should pll_clk be removed from the DT description
>  then, if it's fixed to the oscillator?
> >>> Yes. It is redundant to represent pll_clk in DT, and it should be
> >>> removed.
> >> Why do you think OSC clk determines value of pll_clk?
> >> pll_clk is mapped to SCLK_MIPI[01] or SCLK_DSIM0 gate with few
> >> dividers and muxes above. So at least in theory it can differ from
> >> osc clk. Additionally this gate should be enabled so you cannot
> >> just remove it from DT.
> >>
> >> Regards
> >> Andrzej
> > As I found, pll clk is not SCLK_MIPI[01] but OSC CLK. SCLK_DSIM0
> > must be controlled in this driver as it has been, as a gate clock
> > of MIPI DSI block, but not as a pll clk. SCLK_DSIM0 is not the input
> > clock of MIPI DPHY which provides fin in this code. So clock setting
> > and getting code was wrong, and must be removed.
> >
> > OSC CLK is not soc-depedendant but board-dependant, even though I
> > have not seen any board which does not use OSC CLK by 24 MHz. It
> > must be parsed from board DT file, which in this case, we can use
> > the value in pll_clk_rate (the variable name must be renamed also).
> >
> > Because ambiguous description in the technical document, I can be
> > wrong. Please let me know if I do not understand something. Thanks
> > for your comment.
> 
> After some digging I agree that documentation is quite confusing and
> current code could be wrong. Anyway I wonder if it wouldn't be better
> to explicitly provide input clock for DSIM, or more precisely for its
> PLL instead of hardcoding 24MHz into the driver.

OK. I agree. It will be more explicit to get the clock rate from DT.

> 
> Another thing that bothers me is relation of DPHY_PLL in clock
> controller to MIPI_DPHY in Exynos7420. There are two clocks used by
> MIPI_DPHY:
> - "Ref Clock" pinned to SCLK_MIPIDPHY_M4 connected to OSCCLK,
> - "PHY Clock" pinned to I_FOUT_DPHY_PLL connected to DPHY_PLL,
> 
> The first clock seems to be your osc clock, but what is the role of
> the 2nd one?

Hmm, I couldn't find similar clock in Exynos5433, also I don't have
the manual for Exynos7420.

Best regards,
Hyungwon Hwang


> 
> Regards
> Andrzej
> 
> > Best regards,
> > Hyungwon Hwang
> >
> > Thanks for your review. I will send it again with the changes
> > you suggested.
>  Thanks very much!
> 
>  Cheers,
>  Daniel
> >>> Best regards,
> >>> Hyungwon Hwang
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe
> >>> devicetree" in the body of a message to
> >>> majordomo-u79uwXL29TY76Z2rM5mHXA at public.gmane.org More majordomo
> >>> info at  http://vger.kernel.org/majordomo-info.html
> >>>
> 

[Bug 89734] GL_AMD_pinned_memory extension causing a kernel hardlock

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

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

Bug ID: 89734
   Summary: GL_AMD_pinned_memory extension causing a kernel
hardlock
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: poub365-bugzilla at yahoo.com
QA Contact: dri-devel at lists.freedesktop.org

Kubuntu 15.04, kernel 4.0rc3, amd hd7850 with recent (from ppa oibaf) open
source drivers. Dolphin emulator runs fine except that I have a complete freeze
when I exit. I have to reboot the computer (although it seems to be still
running as I can remotely log with ssh). I tried under kde,  then under icewm,
to see if it was the compositor's fault. No change. Windowed or fullscreen:
same freeze. I tried to stop Dolphin with the interface buttons: same freeze.

kubuntu 15.04, i7 4770k non overclocked, amd hd7850 on open source drivers.

dmesg log is here:
http://pastebin.ca/2962286

I reported the bug to the Dolphin team. Told me that "Basically it's AMD's
GL_AMD_pinned_memory extension causing a kernel hardlock." and that I have to
report here.

-- 
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/20150323/b902cb7c/attachment.html>

[PATCH 03/11] drm: add driver for simple vga encoders

[Heiko Stuebner]

Hi Laurent,

Am Samstag, 28. Februar 2015, 01:42:45 schrieb Heiko Stübner:
> thanks for the comments
> 
> Am Donnerstag, 26. Februar 2015, 20:33:33 schrieb Laurent Pinchart:
> > On Saturday 31 January 2015 17:32:56 Heiko Stuebner wrote:
> > > There exist simple vga encoders without any type of management interface
> > > and just maybe a simple gpio for turning it on or off. Examples for
> > > these
> > > are the Analog Devices ADV7123, Chipsea CS7123 or Micronas SDA7123.
> > > 
> > > Add a generic encoder driver for those that can be used by drm drivers
> > > using the component framework.
> > 
> > The rcar-du driver already handles the adi,adv7123 compatible string used
> > by this driver. A generic driver is in my opinion a very good idea, but
> > we can't break the existing support. Porting the rcar-du driver to the
> > component model is needed.
> 
> is this in someones plans already? Because I'm still having trouble
> understanding parts of the rockchip driver sometimes, so feel in no way
> qualified to try to get this tackled in some reasonable timeframe :-)

currently my idea is to simply do something like the following for this :-)

static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7779" },
{ .compatible = "renesas,du-r8a7790" },
{ .compatible = "renesas,du-r8a7791" },
{ }
};

static int __init vga_encoder_init(void)
{
struct device_node *np;

/*
 * Play nice with rcar-du that is having its own implementation
 * of the adv7123 binding implementation and is not yet
 * converted to using components.
 */
np = of_find_matching_node(NULL, rcar_du_of_table);
if (np) {
of_node_put(np);
return 0;
}

return platform_driver_register(_encoder_driver);
}


slightly similar to what some iommus do


> > > Signed-off-by: Heiko Stuebner 
> > > ---
> > > 
> > >  drivers/gpu/drm/i2c/Kconfig  |   6 +
> > >  drivers/gpu/drm/i2c/Makefile |   2 +
> > >  drivers/gpu/drm/i2c/vga-simple.c | 325
> > >  
> > 
> > drivers/gpu/drm/i2c/ feels wrong for a platform device.
> 
> yep, i2c probably being the wrong place was one of the caveats in the cover
> letter and I was hoping some more seasoned drm people could suggest where
> this should live after all.
> 
> As your comments further down suggest that we might introduce some different
> components, simply congregate them in a "components" subdir or something
> splitting them more?

so does a "components" subdir look reasonable?


> > >  3 files changed, 333 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/i2c/vga-simple.c
> > > 
> > > diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> > > index 22c7ed6..319f2cb 100644
> > > --- a/drivers/gpu/drm/i2c/Kconfig
> > > +++ b/drivers/gpu/drm/i2c/Kconfig
> > > @@ -31,4 +31,10 @@ config DRM_I2C_NXP_TDA998X
> > > 
> > >   help
> > >   
> > > Support for NXP Semiconductors TDA998X HDMI encoders.
> > > 
> > > +config DRM_VGA_SIMPLE
> > > + tristate "Generic simple vga encoder"
> > > + help
> > > +   Support for vga encoder chips without any special settings
> > > +   and at most a power-control gpio.
> > > +
> > > 
> > >  endmenu
> > > 
> > > diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
> > > index 2c72eb5..858961f 100644
> > > --- a/drivers/gpu/drm/i2c/Makefile
> > > +++ b/drivers/gpu/drm/i2c/Makefile
> > > @@ -10,3 +10,5 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
> > > 
> > >  tda998x-y := tda998x_drv.o
> > >  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
> > > 
> > > +
> > > +obj-$(CONFIG_DRM_VGA_SIMPLE) += vga-simple.o
> > > diff --git a/drivers/gpu/drm/i2c/vga-simple.c
> > > b/drivers/gpu/drm/i2c/vga-simple.c new file mode 100644
> > > index 000..bb9d19c
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i2c/vga-simple.c
> > > @@ -0,0 +1,325 @@
> > > +/*
> > > + * Simple vga encoder driver
> > > + *
> > > + * Copyright (C) 2014 Heiko Stuebner 
> > > + *
> > > + * This software is licensed under the terms of the GNU General Public
> > > + * License version 2, as published by the Free Software Foundation, and
> > > + * may be copied, distributed, and modified under those terms.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define connector_to_vga_simple(x) container_of(x, struct vga_simple,
> > > connector) +#define encoder_to_vga_simple(x) container_of(x, struct
> > > vga_simple, encoder) +
> > > 

[git pull] drm fixes

[Dave Jones]

On Mon, Mar 23, 2015 at 11:33:42AM -0400, Josh Boyer wrote:

 > I have a machine that no longer boots in a headless manner with -rc5.
 > It's an Celeron based NUC device.  I blacklisted the i915 driver and
 > it boots fine, then I ran insmod manually and got the backtrace below.
 > This machine only has HDMI output on it.  If I have it connected (even
 > if the monitor is set to display some other input) it will boot fine,
 > but the backtrace is still present.  I'm going to guess the machine
 > "hangs" in headless because X causes some further issues in the
 > headless case.
 > 
 > Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:
 > 
 > [  +0.39] WARNING: CPU: 0 PID: 63 at
 > drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
 > [i915]()
 > [  +0.02] WARN_ON(obj->frontbuffer_bits)
 > 
 > which is what I thought one of these commits was supposed to fix.  I
 > don't see that in -rc5, but then we have these other issues.


 > [  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
 > drm_framebuffer_reference+0x7a/0x90 [drm]()
 ..
 > [  +0.37] WARNING: CPU: 0 PID: 563 at
 > drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
 > [drm]()

I've started seeing this one too as of rc5.
Along with..


=
BUG kmalloc-192 (Tainted: GW  ): Poison overwritten
-
Disabling lock debugging due to kernel taint
INFO: 0x8804277e5c78-0x8804277e5c78. First byte 0x6a instead of 0x6b
INFO: Allocated in ironlake_get_initial_plane_config+0x86/0x390 [i915] age=175 
cpu=5 pid=313
__slab_alloc.constprop.79+0x5a9/0x670
kmem_cache_alloc_trace+0x21f/0x300
ironlake_get_initial_plane_config+0x86/0x390 [i915]
intel_modeset_init+0x9d9/0x1a50 [i915]
i915_driver_load+0xebf/0x1150 [i915]
drm_dev_register+0xb5/0x110 [drm]
drm_get_pci_dev+0x8d/0x200 [drm]
i915_pci_probe+0x3b/0x60 [i915]
pci_device_probe+0x8c/0xf0
driver_probe_device+0x90/0x3e0
__driver_attach+0xa3/0xb0
bus_for_each_dev+0x73/0xc0
driver_attach+0x1e/0x20
bus_add_driver+0x188/0x260
driver_register+0x64/0xf0
__pci_register_driver+0x64/0x70
INFO: Freed in intel_user_framebuffer_destroy+0x65/0xa0 [i915] age=40 cpu=0 
pid=128
__slab_free+0x19e/0x2c0
kfree+0x2c1/0x310
intel_user_framebuffer_destroy+0x65/0xa0 [i915]
drm_framebuffer_free+0x50/0x60 [drm]
drm_framebuffer_unreference+0x35/0x70 [drm]
drm_atomic_helper_plane_destroy_state+0x1f/0x30 [drm_kms_helper]
intel_plane_destroy_state+0xe/0x10 [i915]
drm_plane_helper_commit+0xb2/0x2e0 [drm_kms_helper]
drm_plane_helper_update+0x9a/0xf0 [drm_kms_helper]
__intel_set_mode+0x8b5/0xb70 [i915]
intel_crtc_set_config+0xc4b/0x1030 [i915]
drm_mode_set_config_internal+0x69/0x120 [drm]
restore_fbdev_mode+0xc8/0xf0 [drm_kms_helper]
drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
intel_fbdev_set_par+0x1a/0x60 [i915]
INFO: Slab 0xea00109df900 objects=31 used=31 fp=0x  (null) 
flags=0x80004080
INFO: Object 0x8804277e5c70 @offset=7280 fp=0x8804277e6288
Bytes b4 8804277e5c60: 54 7a fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  
Tz..
Object 8804277e5c70: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b  
jkkk
Object 8804277e5c80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5c90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5ca0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5ce0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5cf0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5d00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5d10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8804277e5d20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  
kkk.
Redzone 8804277e5d30: bb bb bb bb bb bb bb bb  

Padding 8804277e5e70: 5a 5a 5a 5a 5a 5a 5a 5a  

CPU: 4 PID: 128 Comm: kworker/u16:4 Tainted: GB   W   
4.0.0-rc5-backupdebug+ #1
Workqueue: events_unbound async_run_entry_fn
 8804277e5c70 2ebc2945 

[Bug 89034] Firefox crashing xserver and some major rendering bugs

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

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

--- Comment #43 from smoki  ---
Created attachment 114561
  --> https://bugs.freedesktop.org/attachment.cgi?id=114561=edit
hof.png


 Yes, those piglit tests from comment 33 still failing. But also Unigine Valley
still have corruptions, i run it via 'valey' script then apply some setings via
interface. Squares happens regradles of settings on scenes 1, 2, 3 and 6. On 2
and 3 there is not only black squrares, but fog also starts to not render
correctly on some/far camera positions.

 And also Stacking game from comment 24 have same borked rendering. Game Hands
of Fate also show rendering issues (screenshot attached)... and so on, many
apps are affected once i enable subreg liveness.

-- 
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/20150323/09b3c870/attachment-0001.html>

commit 319c1d420a0b (Ensure plane->state->fb stays in sync with plane->fb) cause various errors

[Jani Nikula]

[adding more people and intel-gfx, original message with backtrace at
http://mid.gmane.org/550EED22.9070008 at gmail.com]

On Mon, 23 Mar 2015, François Valenduc  wrote:
> Le 23/03/15 09:52, Jani Nikula a écrit :
>> On Sun, 22 Mar 2015, François Valenduc  
>> wrote:
>>> It seems commit 7ce42ae67c49204c0b2252edd06f7920e0a51037 causes
>>> several errors.
>> It seems I don't have this commit. Which tree is this?
>>
>> I also admit to being pretty bad at associating commit ids with the
>> actual commits, especially so for commit ids I don't have. It would be
>> helpful to include the title of the commit too. ;)
>>
>> BR,
>> Jani.
>>
>>
> Sorry, the id I gave was the one of the revert I made in my local tree.
> The problematic commit is the following:
>
> commit 319c1d420a0b62d9dbb88104afebaabc968cdbfa
> Author: Xi Ruoyao 
> Date:   Thu Mar 12 20:16:32 2015 +0800
>
> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>
> This is a commit which has been merged in the mainline kernel tree
> between 4.0-rc4 and 4.0-rc5.
>
>
> Sincerely yours,
>
> François Valenduc

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH libdrm 9/9] drm: use correct printf modifiers

[Jan Vesely]

On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
> The valies are unsigned long, thus we should use %lu.
> 
> Signed-off-by: Emil Velikov 
> ---
>  xf86drmHash.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xf86drmHash.c b/xf86drmHash.c
> index 12baa62..887d6a7 100644
> --- a/xf86drmHash.c
> +++ b/xf86drmHash.c
> @@ -119,7 +119,7 @@ static unsigned long HashHash(unsigned long key)
>  
>  hash %= HASH_SIZE;
>  #if DEBUG
> -printf( "Hash(%d) = %d\n", key, hash);
> +printf( "Hash(%lu) = %lu\n", key, hash);
>  #endif
>  return hash;
>  }
> @@ -221,8 +221,9 @@ int drmHashInsert(void *t, unsigned long key, void *value)
>  bucket->value= value;
>  bucket->next = table->buckets[hash];
>  table->buckets[hash] = bucket;
> -#if DEBUG
>  printf("Inserted %d at %d/%p\n", key, hash, bucket);
> +#if DEBUG
> +printf("Inserted %lu at %lu/%p\n", key, hash, bucket);
>  #endif

^^ This change looks funny in the patch. I assume you just replace the
printf call? If that's so LGTM
Reviewed-by: Jan Vesely 

>  return 0;/* Added to table */
>  }

-- 
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/20150323/f07ab2bf/attachment.sig>

[PATCH libdrm 8/9] drm: replace HASH_DEBUG with DEBUG

[Jan Vesely]

On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
> ... and remove the useless SL_DEBUG and RANDOM_DEBUG
> 
> Signed-off-by: Emil Velikov 
> ---
>  xf86drmHash.c   | 5 ++---
>  xf86drmRandom.c | 1 -
>  xf86drmSL.c | 1 -
>  3 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/xf86drmHash.c b/xf86drmHash.c
> index 82512a8..12baa62 100644
> --- a/xf86drmHash.c
> +++ b/xf86drmHash.c
> @@ -74,7 +74,6 @@
>  #include "xf86drm.h"
>  
>  #define HASH_MAGIC 0xdeadbeef
> -#define HASH_DEBUG 0
>  #define HASH_SIZE  512   /* Good for about 100 entries */
>   /* If you change this value, you probably
> have to change the HashHash hashing
> @@ -119,7 +118,7 @@ static unsigned long HashHash(unsigned long key)
>  }
>  
>  hash %= HASH_SIZE;
> -#if HASH_DEBUG
> +#if DEBUG
>  printf( "Hash(%d) = %d\n", key, hash);
>  #endif
>  return hash;
> @@ -222,7 +221,7 @@ int drmHashInsert(void *t, unsigned long key, void *value)
>  bucket->value= value;
>  bucket->next = table->buckets[hash];
>  table->buckets[hash] = bucket;
> -#if HASH_DEBUG
> +#if DEBUG
>  printf("Inserted %d at %d/%p\n", key, hash, bucket);
>  #endif
>  return 0;/* Added to table */
> diff --git a/xf86drmRandom.c b/xf86drmRandom.c
> index 39f3c52..2177d27 100644
> --- a/xf86drmRandom.c
> +++ b/xf86drmRandom.c
> @@ -77,7 +77,6 @@
>  #include "xf86drm.h"
>  
>  #define RANDOM_MAGIC 0xfeedbeef
> -#define RANDOM_DEBUG 0
>  
>  typedef struct RandomState {
>  unsigned long magic;
> diff --git a/xf86drmSL.c b/xf86drmSL.c
> index acddb54..9bbf8fb 100644
> --- a/xf86drmSL.c
> +++ b/xf86drmSL.c
> @@ -53,7 +53,6 @@
>  #define SL_ENTRY_MAGIC 0x00fab1edLU
>  #define SL_FREED_MAGIC 0xdecea5edLU
>  #define SL_MAX_LEVEL   16
> -#define SL_DEBUG   0
>  #define SL_RANDOM_SEED 0xc01055a1LU
>  
>  #if SL_MAIN

Reviewed-by: Jan Vesely 

-- 
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/20150323/ddb41366/attachment.sig>

commit 319c1d420a0b (Ensure plane->state->fb stays in sync with plane->fb) cause various errors

[François Valenduc]

Le 23/03/15 09:52, Jani Nikula a écrit :
> On Sun, 22 Mar 2015, François Valenduc  wrote:
>> It seems commit 7ce42ae67c49204c0b2252edd06f7920e0a51037 causes
>> several errors.
> It seems I don't have this commit. Which tree is this?
>
> I also admit to being pretty bad at associating commit ids with the
> actual commits, especially so for commit ids I don't have. It would be
> helpful to include the title of the commit too. ;)
>
> BR,
> Jani.
>
>
Sorry, the id I gave was the one of the revert I made in my local tree.
The problematic commit is the following:

commit 319c1d420a0b62d9dbb88104afebaabc968cdbfa
Author: Xi Ruoyao 
Date:   Thu Mar 12 20:16:32 2015 +0800

drm/i915: Ensure plane->state->fb stays in sync with plane->fb

This is a commit which has been merged in the mainline kernel tree
between 4.0-rc4 and 4.0-rc5.


Sincerely yours,

François Valenduc

[PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators

[Heiko Stuebner]

Hi Philipp,

Am Donnerstag, 12. März 2015, 21:45:19 schrieb Heiko Stuebner:
> At least the Rockchip variant of the dw_hdmi can have controllable power
> supplies providing 1.0 and 1.8V. Therefore add the possibility for the
> generic bridge driver to enable supplies provided by the hw-specific
> drivers.
> 
> Signed-off-by: Heiko Stuebner 

does this look ok now?

And as we talked about in Chemnitz, who will be taking such bridge-related 
changes, as you mentioned some last bridge-patches going through Thierry.


Heiko

> ---
> changes since v2:
> - rename supplies to the names found in the hdmi IP databook
> changes since v1:
> - follow suggestion from Russell King to keep regulator handling local
>   to the rockchip implementation for the time being and only generalize
>   when a real second implementation needs regulator handling
> 
>  .../devicetree/bindings/drm/bridge/dw_hdmi.txt |  5 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 32
> +- 2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
> b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt index
> a905c14..bb74640 100644
> --- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
> +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
> @@ -22,6 +22,11 @@ Optional properties
>  - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
>  - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
> 
> +Optional supplies:
> +rockchip,rk3288-dw-hdmi handles two optional power supplies:
> +- vp-supply: 1.0V power supply
> +- vph-supply: 1.8V power supply
> +
>  Example:
>   hdmi: hdmi at 012 {
>   compatible = "fsl,imx6q-hdmi";
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c index d236faa..647a240 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -28,6 +29,9 @@ struct rockchip_hdmi {
>   struct device *dev;
>   struct regmap *regmap;
>   struct drm_encoder encoder;
> + struct regulator_bulk_data supplies[2];
> + int nsupplies;
> + bool supplies_enabled;
>  };
> 
>  #define to_rockchip_hdmi(x)  container_of(x, struct rockchip_hdmi, x)
> @@ -179,6 +183,12 @@ static struct drm_encoder_funcs
> dw_hdmi_rockchip_encoder_funcs = {
> 
>  static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
>  {
> + struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
> +
> + if (hdmi->nsupplies > 0 && hdmi->supplies_enabled) {
> + regulator_bulk_disable(hdmi->nsupplies, hdmi->supplies);
> + hdmi->supplies_enabled = false;
> + }
>  }
> 
>  static bool
> @@ -199,7 +209,16 @@ static void dw_hdmi_rockchip_encoder_commit(struct
> drm_encoder *encoder) {
>   struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
>   u32 val;
> - int mux;
> + int mux, ret;
> +
> + if (hdmi->nsupplies > 0 && !hdmi->supplies_enabled) {
> + ret = regulator_bulk_enable(hdmi->nsupplies, hdmi->supplies);
> + if (ret) {
> + dev_err(hdmi->dev, "could not enable hdmi analog 
> supplies\n");
> + return;
> + }
> + hdmi->supplies_enabled = true;
> + }
> 
>   mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
>   if (mux)
> @@ -275,6 +294,17 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
> struct device *master, if (!iores)
>   return -ENXIO;
> 
> + hdmi->supplies[0].supply = "vp";
> + hdmi->supplies[1].supply = "vph";
> + hdmi->nsupplies = 2;
> +
> + ret = devm_regulator_bulk_get(hdmi->dev,
> +   hdmi->nsupplies, hdmi->supplies);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + if (ret)
> + hdmi->nsupplies = 0;
> +
>   platform_set_drvdata(pdev, hdmi);
> 
>   encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);

[PATCH libdrm 5/9] tests/hash: return non-zero on failure

[Jan Vesely]

On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
> ... and wire up to `make check' now that it's useful.
> 
> Signed-off-by: Emil Velikov 
> ---
>  tests/Makefile.am | 12 +++-
>  tests/hash.c  | 26 +++---
>  2 files changed, 22 insertions(+), 16 deletions(-)
> 
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index ea826b5..392abf5 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -29,13 +29,15 @@ LDADD = $(top_builddir)/libdrm.la
>  
>  check_PROGRAMS = \
>   dristat \
> - drmstat \
> - hash
> + drmstat
>  
>  if HAVE_NOUVEAU
>  SUBDIRS += nouveau
>  endif
>  
> +TESTS = \
> + hash
> +
>  if HAVE_LIBUDEV
>  
>  check_LTLIBRARIES = libdrmtest.la
> @@ -53,7 +55,7 @@ XFAIL_TESTS =   \
>   auth\
>   lock
>  
> -TESTS =  \
> +TESTS  += \
>   openclose   \
>   getversion  \
>   getclient   \
> @@ -62,6 +64,6 @@ TESTS = \
>   updatedraw  \
>   name_from_fd
>  
> -check_PROGRAMS += $(TESTS)
> -
>  endif
> +
> +check_PROGRAMS += $(TESTS)
> diff --git a/tests/hash.c b/tests/hash.c
> index fa9264a..46f52f8 100644
> --- a/tests/hash.c
> +++ b/tests/hash.c
> @@ -142,7 +142,7 @@ static void compute_dist(HashTablePtr table)
>  }
>  }
>  
> -static void check_table(HashTablePtr table,
> +static int check_table(HashTablePtr table,
>  unsigned long key, unsigned long value)
>  {
>  unsigned long *retval;
> @@ -159,28 +159,32 @@ static void check_table(HashTablePtr table,
> key, value, *retval);
>  break;
>  case 0:
> -if (value != *retval)
> +if (value != *retval) {
>  printf("Bad value: key = %lu, expected = %lu, returned = %lu\n",
> key, value, *retval);
> +retcode = -1;
> +}
>  break;
>  default:
>  printf("Bad retcode = %d: key = %lu, expected = %lu, returned = 
> %lu\n",
> retcode, key, value, *retval);
>  break;
>  }
> +return retcode;
>  }
>  
>  int main(void)
>  {
> -HashTablePtr table;
> -unsigned long  i;
> +HashTablePtr  table;
> +unsigned long i;
> +int   ret = 0;
>  
>  printf("\n* 256 consecutive integers \n");
>  table = drmHashCreate();
>  for (i = 0; i < 256; i++)
>  drmHashInsert(table, i, (void *));
>  for (i = 0; i < 256; i++)
> -check_table(table, i, i);
> +ret = check_table(table, i, i) && ret;
>  compute_dist(table);
>  drmHashDestroy(table);
>  
> @@ -189,7 +193,7 @@ int main(void)
>  for (i = 0; i < 1024; i++)
>  drmHashInsert(table, i, (void *));
>  for (i = 0; i < 1024; i++)
> -check_table(table, i, i);
> +ret = check_table(table, i, i) && ret;
>  compute_dist(table);
>  drmHashDestroy(table);
>  
> @@ -198,7 +202,7 @@ int main(void)
>  for (i = 0; i < 1024; i++)
>  drmHashInsert(table, i*4096, (void *));
>  for (i = 0; i < 1024; i++)
> -check_table(table, i*4096, i);
> +ret = check_table(table, i*4096, i) && ret;
>  compute_dist(table);
>  drmHashDestroy(table);
>  
> @@ -209,10 +213,10 @@ int main(void)
>  drmHashInsert(table, random(), (void *));
>  srandom(0xbeefbeef);
>  for (i = 0; i < 1024; i++)
> -check_table(table, random(), i);
> +ret = check_table(table, random(), i) && ret;
>  srandom(0xbeefbeef);
>  for (i = 0; i < 1024; i++)
> -check_table(table, random(), i);
> +ret = check_table(table, random(), i) && ret;
>  compute_dist(table);
>  drmHashDestroy(table);
>  
> @@ -223,10 +227,10 @@ int main(void)
>  drmHashInsert(table, random(), (void *));
>  srandom(0xbeefbeef);
>  for (i = 0; i < 5000; i++)
> -check_table(table, random(), i);
> +ret = check_table(table, random(), i) && ret;
>  srandom(0xbeefbeef);
>  for (i = 0; i < 5000; i++)
> -check_table(table, random(), i);
> +ret = check_table(table, random(), i) && ret;
>  compute_dist(table);
>  drmHashDestroy(table);
>  
Reviewed-by: Jan Vesely 

-- 
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/20150323/bea5ac91/attachment.sig>

[PATCH libdrm 4/9] tests/hash: style fixes

[Jan Vesely]

f("Bad value: key = %lu, expected = %lu, returned = %lu\n",
> +   key, value, *retval);
> +break;
>  default:
> - printf("Bad retcode = %d: key = %lu, expected = %lu, returned = %lu\n",
> -retcode, key, value, *retval);
> - break;
> +printf("Bad retcode = %d: key = %lu, expected = %lu, returned = 
> %lu\n",
> +   retcode, key, value, *retval);
> +break;
>  }
>  }
>  
> @@ -171,44 +177,56 @@ int main(void)
>  
>  printf("\n* 256 consecutive integers \n");
>  table = drmHashCreate();
> -for (i = 0; i < 256; i++) drmHashInsert(table, i, (void *));
> -for (i = 0; i < 256; i++) check_table(table, i, i);
> +for (i = 0; i < 256; i++)
> +drmHashInsert(table, i, (void *));
> +for (i = 0; i < 256; i++)
> +check_table(table, i, i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  
>  printf("\n* 1024 consecutive integers \n");
>  table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i, (void *));
> -for (i = 0; i < 1024; i++) check_table(table, i, i);
> +for (i = 0; i < 1024; i++)
> +drmHashInsert(table, i, (void *));
> +for (i = 0; i < 1024; i++)
> +check_table(table, i, i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  
>  printf("\n* 1024 consecutive page addresses (4k pages) \n");
>  table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, (void *));
> -for (i = 0; i < 1024; i++) check_table(table, i*4096, i);
> +for (i = 0; i < 1024; i++)
> +drmHashInsert(table, i*4096, (void *));
> +for (i = 0; i < 1024; i++)
> +check_table(table, i*4096, i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  
>  printf("\n* 1024 random integers \n");
>  table = drmHashCreate();
>  srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) drmHashInsert(table, random(), (void *));
> +for (i = 0; i < 1024; i++)
> +drmHashInsert(table, random(), (void *));
>  srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) check_table(table, random(), i);
> +for (i = 0; i < 1024; i++)
> +check_table(table, random(), i);
>  srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) check_table(table, random(), i);
> +for (i = 0; i < 1024; i++)
> +check_table(table, random(), i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  
>  printf("\n* 5000 random integers \n");
>  table = drmHashCreate();
>  srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) drmHashInsert(table, random(), (void *));
> +for (i = 0; i < 5000; i++)
> +drmHashInsert(table, random(), (void *));
>  srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> +for (i = 0; i < 5000; i++)
> +check_table(table, random(), i);
>  srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> +for (i = 0; i < 5000; i++)
> +check_table(table, random(), i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  

-- 
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/20150323/6b066f5b/attachment-0001.sig>

[PATCH libdrm 3/9] tests/hash: misc compilation fixes

[Jan Vesely]

On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
> Get the test from completely broken to working like a charm.
> 
>  - Use the same variable type for both HashInsert and HashLookup.
>  - Use correct storage type for the HashLookup return value.
>  - Remove useless backward iteration of HashLookup(i).
> 
> Signed-off-by: Emil Velikov 
> ---
>  tests/hash.c | 31 ++-
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/tests/hash.c b/tests/hash.c
> index d57d2dc..902919f 100644
> --- a/tests/hash.c
> +++ b/tests/hash.c
> @@ -139,27 +139,27 @@ static void compute_dist(HashTablePtr table)
>  static void check_table(HashTablePtr table,
>   unsigned long key, unsigned long value)

I think we should use void* for value here.

>  {
> -unsigned long retval  = 0;
> -int   retcode = drmHashLookup(table, key, );
> +unsigned long *retval;
> +int   retcode = drmHashLookup(table, key, (void **));

I don't think this is correct. If the entry is found, it stores address
to stack variable i in retval, which at this point in iteration
incidentally contains the value we are looking for.

>  
>  switch (retcode) {
>  case -1:
>   printf("Bad magic = 0x%08lx:"
>  " key = %lu, expected = %lu, returned = %lu\n",
> -table->magic, key, value, retval);
> +table->magic, key, value, *retval);
>   break;
>  case 1:
> - printf("Not found: key = %lu, expected = %lu returned = %lu\n",
> -key, value, retval);
> + printf("Not found: key = %lu, expected = %lu, returned = %lu\n",
> +key, value, *retval);
>   break;
>  case 0:
> - if (value != retval)
> + if (value != *retval)
>   printf("Bad value: key = %lu, expected = %lu, returned = %lu\n",
> -key, value, retval);
> +key, value, *retval);
>   break;
>  default:
>   printf("Bad retcode = %d: key = %lu, expected = %lu, returned = %lu\n",
> -retcode, key, value, retval);
> +retcode, key, value, *retval);
>   break;
>  }
>  }
> @@ -167,36 +167,33 @@ static void check_table(HashTablePtr table,
>  int main(void)
>  {
>  HashTablePtr table;
> -int  i;
> +unsigned long  i;
>  
>  printf("\n* 256 consecutive integers \n");
>  table = drmHashCreate();
> -for (i = 0; i < 256; i++) drmHashInsert(table, i, i);
> +for (i = 0; i < 256; i++) drmHashInsert(table, i, (void *));

This changes the entries inserted. previously it would insert values [0,
256). Now it inserts address of i 256 times.
I think we should change the inserted values to be different from the
key (offset should be enough), to catch the kind of scenario this tests
creates.

>  for (i = 0; i < 256; i++) check_table(table, i, i);
> -for (i = 256; i >= 0; i--) check_table(table, i, i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  
>  printf("\n* 1024 consecutive integers \n");
>  table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i, i);
> +for (i = 0; i < 1024; i++) drmHashInsert(table, i, (void *));
>  for (i = 0; i < 1024; i++) check_table(table, i, i);
> -for (i = 1024; i >= 0; i--) check_table(table, i, i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  
>  printf("\n* 1024 consecutive page addresses (4k pages) \n");
>  table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, i);
> +for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, (void *));
>  for (i = 0; i < 1024; i++) check_table(table, i*4096, i);
> -for (i = 1024; i >= 0; i--) check_table(table, i*4096, i);
>  compute_dist(table);
>  drmHashDestroy(table);
>  
>  printf("\n* 1024 random integers \n");
>  table = drmHashCreate();
>  srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) drmHashInsert(table, random(), i);
> +for (i = 0; i < 1024; i++) drmHashInsert(table, random(), (void *));
>  srandom(0xbeefbeef);
>  for (i = 0; i < 1024; i++) check_table(table, random(), i);
>  srandom(0xbeefbeef);
> @@ -207,7 +204,7 @@ int main(void)
>  printf("\n* 5000 random integers \n");
>  table = drmHashCreate();
>  srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) drmHashInsert(table, random(), i);
> +for (i = 0; i < 5000; i++) drmHashInsert(table, random(), (void *));
>  srandom(0xbeefbeef);
>  for (i = 0; i < 5000; i++) check_table(table, random(), i);
>  srandom(0xbeefbeef);

-- 
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/20150323/0a4319c6/attachment.sig>

[PATCH] drm/msm: Refactor msm drm driver by introducing msm_drm_sub_dev

[Rob Clark]

On Thu, Mar 12, 2015 at 4:48 PM, Jilai Wang  wrote:
> Introduce msm_drm_sub_dev for each mdp interface component such as
> HDMI/eDP/DSI to contain common information shared with MDP.
>
> Signed-off-by: Jilai Wang 
> ---
>  drivers/gpu/drm/msm/edp/edp.c   | 18 +--
>  drivers/gpu/drm/msm/edp/edp.h   |  1 +
>  drivers/gpu/drm/msm/hdmi/hdmi.c | 22 ++---
>  drivers/gpu/drm/msm/hdmi/hdmi.h |  1 +
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c |  3 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 56 
> -
>  drivers/gpu/drm/msm/msm_drv.h   | 23 +-
>  7 files changed, 80 insertions(+), 44 deletions(-)

So a couple comments..

1) I kinda prefer having some to_hdmi/to_edp/etc macros rather than
just open coding container_of().. I guess kind of a minor thing, but
it keeps things consistent with how "inheritance" is handled elsewhere
(like to_mdp5_crtc(), etc)

2) I'd be a bit more enthused by this when it actually results in a
negative diffstat, rather than a positive one.  Not saying it isn't
something we should do at some point, but at this point I'm leaning
towards rebasing the DSI patcheset to not depend on this for now.

BR,
-R

>
> diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
> index 0940e84..8d8b7e9 100644
> --- a/drivers/gpu/drm/msm/edp/edp.c
> +++ b/drivers/gpu/drm/msm/edp/edp.c
> @@ -14,6 +14,9 @@
>  #include 
>  #include "edp.h"
>
> +static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
> +   struct drm_device *dev);
> +
>  static irqreturn_t edp_irq(int irq, void *dev_id)
>  {
> struct msm_edp *edp = dev_id;
> @@ -63,6 +66,8 @@ static struct msm_edp *edp_init(struct platform_device 
> *pdev)
> if (ret)
> goto fail;
>
> +   edp->base.modeset_init = msm_edp_modeset_init;
> +
> return edp;
>
>  fail:
> @@ -82,7 +87,8 @@ static int edp_bind(struct device *dev, struct device 
> *master, void *data)
> edp = edp_init(to_platform_device(dev));
> if (IS_ERR(edp))
> return PTR_ERR(edp);
> -   priv->edp = edp;
> +
> +   priv->edp = >base;
>
> return 0;
>  }
> @@ -144,13 +150,19 @@ void __exit msm_edp_unregister(void)
>  }
>
>  /* Second part of initialization, the drm/kms level modeset_init */
> -int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
> -   struct drm_encoder *encoder)
> +static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
> +   struct drm_device *dev)
>  {
> +   struct msm_edp *edp = container_of(base, struct msm_edp, base);
> struct platform_device *pdev = edp->pdev;
> struct msm_drm_private *priv = dev->dev_private;
> +   struct drm_encoder *encoder;
> int ret;
>
> +   if (WARN_ON(base->num_encoders != 1))
> +   return -EINVAL;
> +
> +   encoder = base->encoders[0];
> edp->encoder = encoder;
> edp->dev = dev;
>
> diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h
> index ba5bedd..00eff68 100644
> --- a/drivers/gpu/drm/msm/edp/edp.h
> +++ b/drivers/gpu/drm/msm/edp/edp.h
> @@ -31,6 +31,7 @@ struct edp_aux;
>  struct edp_phy;
>
>  struct msm_edp {
> +   struct msm_drm_sub_dev base;
> struct drm_device *dev;
> struct platform_device *pdev;
>
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
> index 9a8a825..9e886ec 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
> @@ -19,6 +19,9 @@
>  #include 
>  #include "hdmi.h"
>
> +static int hdmi_modeset_init(struct msm_drm_sub_dev *base,
> +   struct drm_device *dev);
> +
>  void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
>  {
> uint32_t ctrl = 0;
> @@ -197,6 +200,8 @@ static struct hdmi *hdmi_init(struct platform_device 
> *pdev)
> goto fail;
> }
>
> +   hdmi->base.modeset_init = hdmi_modeset_init;
> +
> return hdmi;
>
>  fail:
> @@ -214,13 +219,19 @@ fail:
>   * should be handled in hdmi_init() so that failure happens from
>   * hdmi sub-device's probe.
>   */
> -int hdmi_modeset_init(struct hdmi *hdmi,
> -   struct drm_device *dev, struct drm_encoder *encoder)
> +static int hdmi_modeset_init(struct msm_drm_sub_dev *base,
> +   struct drm_device *dev)
>  {
> +   struct hdmi *hdmi = container_of(base, struct hdmi, base);
> struct msm_drm_private *priv = dev->dev_private;
> struct platform_device *pdev = hdmi->pdev;
> +   struct drm_encoder *encoder;
> int ret;
>
> +   if (WARN_ON(base->num_encoders != 1))
> +   return -EINVAL;
> +
> +   encoder = base->encoders[0];
> hdmi->dev = dev;
> hdmi->encoder = encoder;
>
> @@ -439,7 +450,8 @@ static int hdmi_bind(struct device *dev, struct device 
> *master, void *data)
> hdmi = 

[PATCH libdrm 2/9] tests/hash: extract test out of xf86drmHash.c

[Jan Vesely]

te_dist(HashTablePtr table)
> -{
> -int   i;
> -HashBucketPtr bucket;
> -
> -printf("Entries = %ld, hits = %ld, partials = %ld, misses = %ld\n",
> -table->entries, table->hits, table->partials, table->misses);
> -clear_dist();
> -for (i = 0; i < HASH_SIZE; i++) {
> - bucket = table->buckets[i];
> - update_dist(count_entries(bucket));
> -}
> -for (i = 0; i < DIST_LIMIT; i++) {
> - if (i != DIST_LIMIT-1) printf("%5d %10d\n", i, dist[i]);
> - else   printf("other %10d\n", dist[i]);
> -}
> -}
> -
> -static void check_table(HashTablePtr table,
> - unsigned long key, unsigned long value)
> -{
> -unsigned long retval  = 0;
> -int   retcode = drmHashLookup(table, key, );
> -
> -switch (retcode) {
> -case -1:
> - printf("Bad magic = 0x%08lx:"
> -" key = %lu, expected = %lu, returned = %lu\n",
> -table->magic, key, value, retval);
> - break;
> -case 1:
> - printf("Not found: key = %lu, expected = %lu returned = %lu\n",
> -key, value, retval);
> - break;
> -case 0:
> - if (value != retval)
> - printf("Bad value: key = %lu, expected = %lu, returned = %lu\n",
> -key, value, retval);
> - break;
> -default:
> - printf("Bad retcode = %d: key = %lu, expected = %lu, returned = %lu\n",
> -retcode, key, value, retval);
> - break;
> -}
> -}
> -
> -int main(void)
> -{
> -HashTablePtr table;
> -int  i;
> -
> -printf("\n* 256 consecutive integers \n");
> -table = drmHashCreate();
> -for (i = 0; i < 256; i++) drmHashInsert(table, i, i);
> -for (i = 0; i < 256; i++) check_table(table, i, i);
> -for (i = 256; i >= 0; i--) check_table(table, i, i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 1024 consecutive integers \n");
> -    table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i, i);
> -for (i = 0; i < 1024; i++) check_table(table, i, i);
> -for (i = 1024; i >= 0; i--) check_table(table, i, i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 1024 consecutive page addresses (4k pages) \n");
> -table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, i);
> -for (i = 0; i < 1024; i++) check_table(table, i*4096, i);
> -for (i = 1024; i >= 0; i--) check_table(table, i*4096, i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 1024 random integers \n");
> -table = drmHashCreate();
> -srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) drmHashInsert(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) check_table(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) check_table(table, random(), i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 5000 random integers \n");
> -table = drmHashCreate();
> -srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) drmHashInsert(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -return 0;
> -}
> -#endif

-- 
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/20150323/a40241e3/attachment-0001.sig>

[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1

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

https://bugzilla.kernel.org/show_bug.cgi?id=61941

--- Comment #24 from Mihai Coman  ---
Still happens on 3.19.2-1-ARCH. After blanking, sometimes the image comes back
on; I can move the cursor, but the interface is unresponsive.

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

[PATCH libdrm 1/9] tests/dristat: don't include C files

[Jan Vesely]

On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
> Remove the hack of including C files, by reworking the only requirement
> drmOpenMinor() to an open(buf...). After all we do know the exact name
> of the device we're going to open, so might as well use it. Replace
> hard-coded 16 with DRM_MAX_MINOR while we're here.
> 
> Signed-off-by: Emil Velikov 
> ---
>  tests/dristat.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/tests/dristat.c b/tests/dristat.c
> index cca4b03..cc23e16 100644
> --- a/tests/dristat.c
> +++ b/tests/dristat.c
> @@ -31,13 +31,14 @@
>  # include 
>  #endif
>  
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include "xf86drm.h"
> -#include "xf86drmRandom.c"
> -#include "xf86drmHash.c"
> -#include "xf86drm.c"
>  
>  #define DRM_VERSION 0x0001
>  #define DRM_MEMORY  0x0002
> @@ -267,9 +268,9 @@ int main(int argc, char **argv)
>   return 1;
>   }
>  
> -for (i = 0; i < 16; i++) if (!minor || i == minor) {
> +for (i = 0; i < DRM_MAX_MINOR; i++) if (!minor || i == minor) {
>   sprintf(buf, DRM_DEV_NAME, DRM_DIR_NAME, i);
> - fd = drmOpenMinor(i, 1, DRM_NODE_PRIMARY);
> + fd = open(buf, O_RDWR, 0);

What about the "create" (second) argument? The original code creates the
node if it does not exist (on non-UDEV systems), or waits some time for
udev to create it.
Not sure how this is relevant for the test.


>   if (fd >= 0) {
>   printf("%s\n", buf);
>   if (mask & DRM_BUSID)   getbusid(fd);

-- 
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/20150323/aecd6028/attachment.sig>

[PATCH 7/7] drm/exynos: track vblank events on a per crtc basis

[Gustavo Padovan]

From: Mandeep Singh Baines 

The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.

Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.

Signed-off-by: Mandeep Singh Baines 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 92 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  | 13 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  6 +--
 3 files changed, 44 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 47dd2b0..eb49195 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
-   !atomic_read(_crtc->pending_flip),
-   HZ/20))
-   atomic_set(_crtc->pending_flip, 0);
+   (exynos_crtc->event == NULL), HZ/20))
+   exynos_crtc->event = NULL;
drm_crtc_vblank_off(crtc);
}

@@ -164,11 +163,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
 uint32_t page_flip_flags)
 {
struct drm_device *dev = crtc->dev;
-   struct exynos_drm_private *dev_priv = dev->dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
-   int ret = -EINVAL;
+   int ret;

/* when the page flip is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -176,48 +174,49 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
return -EINVAL;
}

-   mutex_lock(>struct_mutex);
+   if (!event)
+   return -EINVAL;

-   if (event) {
-   /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
-   event->pipe = exynos_crtc->pipe;
+   spin_lock_irq(>event_lock);
+   if (exynos_crtc->event) {
+   ret = -EBUSY;
+   goto out;
+   }

-   ret = drm_vblank_get(dev, exynos_crtc->pipe);
-   if (ret) {
-   DRM_DEBUG("failed to acquire vblank counter\n");
+   ret = drm_vblank_get(dev, exynos_crtc->pipe);
+   if (ret) {
+   DRM_DEBUG("failed to acquire vblank counter\n");
+   goto out;
+   }

-   goto out;
-   }
+   exynos_crtc->event = event;
+   spin_unlock_irq(>event_lock);

+   /*
+* the pipe from user always is 0 so we can set pipe number
+* of current owner to event.
+*/
+   event->pipe = exynos_crtc->pipe;
+
+   crtc->primary->fb = fb;
+   crtc_w = fb->width - crtc->x;
+   crtc_h = fb->height - crtc->y;
+   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, crtc->x, crtc->y,
+ crtc_w, crtc_h);
+   if (ret) {
+   crtc->primary->fb = old_fb;
spin_lock_irq(>event_lock);
-   list_add_tail(>base.link,
-   _priv->pageflip_event_list);
-   atomic_set(_crtc->pending_flip, 1);
+   exynos_crtc->event = NULL;
+   drm_vblank_put(dev, exynos_crtc->pipe);
spin_unlock_irq(>event_lock);
-
-   crtc->primary->fb = fb;
-   crtc_w = fb->width - crtc->x;
-   crtc_h = fb->height - crtc->y;
-   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
-   if (ret) {
-   crtc->primary->fb = old_fb;
-
-   spin_lock_irq(>event_lock);
-   drm_vblank_put(dev, exynos_crtc->pipe);
-   list_del(>base.link);
-   atomic_set(_crtc->pending_flip, 0);
-   spin_unlock_irq(>event_lock);
-
-   goto out;
-   }
+   return ret;
}
+
+   return 0;
+
 out:
-   mutex_unlock(>struct_mutex);
+   spin_unlock_irq(>event_lock);
 

[PATCH 6/7] drm/exynos: remove leftover functions declarations

[Gustavo Padovan]

From: Gustavo Padovan 

These functions were already removed by previous cleanup work, but these
ones were left behind.

Signed-off-by: Gustavo Padovan 
Acked-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index e1fd2ef..0ecd8fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -28,12 +28,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device *dev, 
int pipe);
 void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe);
 void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb);

-void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc,
-   struct exynos_drm_plane *plane);
-void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos);
-void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
-void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);
-
 /* This function gets pipe value to crtc device matched with out_type. */
 int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
unsigned int out_type);
-- 
2.1.0

[PATCH 5/7] drm/exynos: remove exynos_plane_destroy()

[Gustavo Padovan]

From: Gustavo Padovan 

The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 2fbac9b..2b0479e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -178,16 +178,10 @@ static int exynos_disable_plane(struct drm_plane *plane)
return 0;
 }

-static void exynos_plane_destroy(struct drm_plane *plane)
-{
-   exynos_disable_plane(plane);
-   drm_plane_cleanup(plane);
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = exynos_update_plane,
.disable_plane  = exynos_disable_plane,
-   .destroy= exynos_plane_destroy,
+   .destroy= drm_plane_cleanup,
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
-- 
2.1.0

[PATCH 4/7] drm/exynos: make zpos property immutable

[Gustavo Padovan]

From: Gustavo Padovan 

We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 504bd6e..2fbac9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -184,27 +184,10 @@ static void exynos_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
 }

-static int exynos_plane_set_property(struct drm_plane *plane,
-struct drm_property *property,
-uint64_t val)
-{
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_private *dev_priv = dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property) {
-   exynos_plane->zpos = val;
-   return 0;
-   }
-
-   return -EINVAL;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = exynos_update_plane,
.disable_plane  = exynos_disable_plane,
.destroy= exynos_plane_destroy,
-   .set_property   = exynos_plane_set_property,
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
@@ -216,8 +199,8 @@ static void exynos_plane_attach_zpos_property(struct 
drm_plane *plane,

prop = dev_priv->plane_zpos_property;
if (!prop) {
-   prop = drm_property_create_range(dev, 0, "zpos", 0,
-MAX_PLANE - 1);
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+"zpos", 0, MAX_PLANE - 1);
if (!prop)
return;

-- 
2.1.0

[PATCH 3/7] drm/exynos: preset zpos value for overlay planes

[Gustavo Padovan]

From: Gustavo Padovan 

Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.

Also all places that were storing zpos positions are now unsigned int.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 20 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  7 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c  | 16 +---
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |  3 ++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 17 +
 drivers/gpu/drm/exynos/exynos_mixer.c  | 11 +--
 7 files changed, 37 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 2cbe328..bee1f72 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -378,7 +378,7 @@ static void decon_win_set_colkey(struct decon_context *ctx, 
unsigned int win)
  * @protect: 1 to protect (disable updates)
  */
 static void decon_shadow_protect_win(struct decon_context *ctx,
-   int win, bool protect)
+unsigned int win, bool protect)
 {
u32 bits, val;

@@ -392,12 +392,12 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx,
writel(val, ctx->regs + SHADOWCON);
 }

-static void decon_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
 {
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *mode = >base.mode;
struct exynos_drm_plane *plane;
-   int padding, win = zpos;
+   int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
@@ -405,9 +405,6 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc, 
int zpos)
if (ctx->suspended)
return;

-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;

@@ -513,16 +510,12 @@ static void decon_win_commit(struct exynos_drm_crtc 
*crtc, int zpos)
plane->enabled = true;
 }

-static void decon_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
 {
struct decon_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
-   int win = zpos;
u32 val;

-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;

@@ -764,7 +757,8 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
enum drm_plane_type type;
-   int zpos, ret;
+   unsigned int zpos;
+   int ret;

ret = decon_ctx_initialize(ctx, drm_dev);
if (ret) {
@@ -776,7 +770,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, >planes[zpos], 1 << ctx->pipe,
- type);
+ type, zpos);
}

exynos_plane = >planes[ctx->default_win];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8a2f943..26d6de1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -21,7 +21,6 @@
 #define MAX_CRTC   3
 #define MAX_PLANE  5
 #define MAX_FB_BUFFER  4
-#define DEFAULT_ZPOS   -1

 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc, base)
 #define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
@@ -104,7 +103,7 @@ struct exynos_drm_plane {
unsigned int pitch;
uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
-   int zpos;
+   unsigned int zpos;
unsigned int index_color;

bool default_win:1;
@@ -189,8 +188,8 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
-   void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
-   void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
+   void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+   

[PATCH 2/7] drm/exynos: remove struct *_win_data abstraction on planes

[Gustavo Padovan]

From: Gustavo Padovan 

struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.

It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.

v2: allocate each plane separated instead of static define them in
the drivers' context struct.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 164 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   9 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  14 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   5 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 192 ++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  23 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 133 +
 drivers/gpu/drm/exynos/exynos_mixer.c  | 223 +++--
 10 files changed, 270 insertions(+), 500 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..2cbe328 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -28,6 +28,7 @@
 #include 

 #include "exynos_drm_crtc.h"
+#include "exynos_drm_plane.h"
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_iommu.h"
@@ -41,32 +42,16 @@

 #define WINDOWS_NR 2

-struct decon_win_data {
-   unsigned intovl_x;
-   unsigned intovl_y;
-   unsigned intoffset_x;
-   unsigned intoffset_y;
-   unsigned intovl_width;
-   unsigned intovl_height;
-   unsigned intfb_width;
-   unsigned intfb_height;
-   unsigned intbpp;
-   unsigned intpixel_format;
-   dma_addr_t  dma_addr;
-   boolenabled;
-   boolresume;
-};
-
 struct decon_context {
struct device   *dev;
struct drm_device   *drm_dev;
struct exynos_drm_crtc  *crtc;
+   struct exynos_drm_plane planes[WINDOWS_NR];
struct clk  *pclk;
struct clk  *aclk;
struct clk  *eclk;
struct clk  *vclk;
void __iomem*regs;
-   struct decon_win_data   win_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long   irq_flags;
booli80_if;
@@ -296,59 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
}
 }

-static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
-   struct exynos_drm_plane *plane)
-{
-   struct decon_context *ctx = crtc->ctx;
-   struct decon_win_data *win_data;
-   int win, padding;
-
-   if (!plane) {
-   DRM_ERROR("plane is NULL\n");
-   return;
-   }
-
-   win = plane->zpos;
-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
-   if (win < 0 || win >= WINDOWS_NR)
-   return;
-
-
-   win_data = >win_data[win];
-
-   padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
-   win_data->offset_x = plane->fb_x;
-   win_data->offset_y = plane->fb_y;
-   win_data->fb_width = plane->fb_width + padding;
-   win_data->fb_height = plane->fb_height;
-   win_data->ovl_x = plane->crtc_x;
-   win_data->ovl_y = plane->crtc_y;
-   win_data->ovl_width = plane->crtc_width;
-   win_data->ovl_height = plane->crtc_height;
-   win_data->dma_addr = plane->dma_addr[0];
-   win_data->bpp = plane->bpp;
-   win_data->pixel_format = plane->pixel_format;
-
-   DRM_DEBUG_KMS("offset_x = %d, offset_y = %d\n",
-   win_data->offset_x, win_data->offset_y);
-   DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
-   win_data->ovl_width, win_data->ovl_height);
-   DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
-   DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
-   plane->fb_width, plane->crtc_width);
-}
-
 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
 {
-   struct decon_win_data *win_data = >win_data[win];
+   struct exynos_drm_plane *plane = >planes[win];
unsigned long val;
+   int padding;

val = readl(ctx->regs + WINCON(win));
val &= ~WINCONx_BPPMODE_MASK;

-   switch (win_data->pixel_format) {
+   switch (plane->pixel_format) {
case DRM_FORMAT_RGB565:
val |= 

[PATCH 1/7] drm/exynos: remove unused exynos_crtc->win_enable() callback

[Gustavo Padovan]

From: Gustavo Padovan 

None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9afd390..4e8f0b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -174,7 +174,6 @@ struct exynos_drm_display {
  * hardware overlay is updated.
  * @win_mode_set: copy drm overlay info to hw specific overlay info.
  * @win_commit: apply hardware specific overlay data to registers.
- * @win_enable: enable hardware specific overlay.
  * @win_disable: disable hardware specific overlay.
  * @te_handler: trigger to transfer video image at the tearing effect
  * synchronization signal if there is a page flip request.
@@ -192,7 +191,6 @@ struct exynos_drm_crtc_ops {
void (*win_mode_set)(struct exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane);
void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
-   void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
 };
-- 
2.1.0

[PATCH 0/7] drm/exynos: clean up patches (preparing for atomic)

[Gustavo Padovan]

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.

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   | 205 ++
 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   | 144 ++
 drivers/gpu/drm/exynos/exynos_mixer.c  | 228 +++--
 10 files changed, 339 insertions(+), 642 deletions(-)

-- 
2.1.0

[Bug 89034] Firefox crashing xserver and some major rendering bugs

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

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

--- Comment #42 from Tom Stellard  ---
(In reply to smoki from comment #41)
>  Tried svn232842 with subreg liveness enabled + mesa 
> a04b520890c669ce012b4b18165392dcabe0b27b
> 
>  Nothing, still same bugs are there.

I can't reproduce any of these failures on my Verde card.  What is still
failing for you? Piglit tests?  If you still see corruption in Unigine Valley,
can you post the command you use to launch the program and which scene the
corruption occurs in?

-- 
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/20150323/923886d8/attachment.html>

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

["Stéphane Viau"]

Hi Archit,

> Hi Stephane,
>
> On 03/14/2015 01:19 AM, Stephane Viau wrote:
>> 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,
>
> msm8x16 would require a flush_hw_mask too, it should be 0x32a59 if I'm
> not wrong. Could you please add it for the next revision, or as a part
> of the 8x16 hw cfg patch?

Correct; thanks for pointing this out.

IMO, this value should be 0x4003 because the fields are actually
present in the register (even though the interfaces/pipes.etc. are not).
Anyway, these bits won't be accessed because the driver won't even allow
the usage of the corresponding resources.

I will update in the v2 of "drm/msm/mdp5: Add hardware configuration for
msm8x16".

Thanks,
Stephane.

>
> Thanks,
> Archit
>
> --
> 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 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[Javi Merino]

On Mon, Mar 23, 2015 at 12:34:04PM +, Jeff Epler wrote:
> On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
> > +/*
> > + * Same as above but for u64 dividends.  divisor must be a 32-bit
> > + * number.
> > + */
> > +#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \
> > +{  \
> > +   unsigned long long _tmp = (x) + (divisor) / 2;  \
> > +   do_div(_tmp, divisor);  \
> > +   _tmp;   \
> > +}  \
> > +)
> 
> The macro evaluates 'divisor' twice.

Good catch.  That needs to be fixed.  I could do the typeof trick that
DIV_ROUND_CLOSEST() does but it's probably better to just create a
static function as Alex Elder suggests.  I'll send a v2 tomorrow with
a static function instead.

Cheers,
Javi

[RFC PATCH 00/37] Modesetting for atomic modesetting

[Daniel Stone]

Hi,

On 23 March 2015 at 08:20, Daniel Vetter  wrote:
> On Thu, Mar 19, 2015 at 04:32:36AM +, Daniel Stone wrote:
>> This series ends up touching pretty much all the drivers, by virtue of 
>> turning
>> crtc->mode (in particular) into both a const and a pointer.
>
> Ok this is quite a bit a different beast than what I expected. I think
> it's way too intrusive for drivers to land quickly, and there's a big
> depency chain linking everything. I think we need something much simpler.

Yeah, I'm uneasy with how invasive it's got: hence the proposal to
drop crtc->mode back into being inlined. I don't think we lose
anything from doing that (as crtc->state->mode still changes), and
that makes the diff much less scary. The constness changes no longer
become required, but I think are still pretty useful from the point of
view of setting (and enforcing) our existing expectations. I'd still
look to push those anyway, but at a much more sedate pace.

>>   - as far as possible, modes should be relateable to their source, e.g. if
>> Plymouth pulls a particular mode from the encoder, and you pick up on 
>> that
>> mode as part of current configuration during handover, you should be able
>> to work backwards to where Plymouth sourced it, i.e. the encoder list
>
> With legacy setcrtc we already lose this information and thus far no one
> seems to have cared. And I don't see the use-case since simply comparing
> it to sources works well enough, in case you want to know where a mode is
> from.

On the other hand, I wouldn't suggest SetCrtc to really be a model to
follow. I really don't mind SetCrtc breaking all these expectations
above, mind.

>>   - userspace should be able to tell the current status by looking at the IDs
>> returned by property queries, rather than having to pull the entire mode
>> out: if we make them do that, they won't bother minimising the deltas and
>> will just dump the full state in every time, and that makes debugging the
>> entire thing that much harder
>
> That doesn't work since idr eagerly reuses ids. Just by looking at the id
> you can't tell whether it's the same object or a new one accidentally
> reusing the same id slot. You always have to re-read the blob property too
> to reconstruct state.

Do we make any guarantee on connector->modes lifetimes? If it can't
change without a hotplug event, then we know the ID is valid until the
connector goes dark, at which point we have to drop any local cache
relating to it.

Saying that userspace must read every single mode property back every
single time is pretty horrible from the point of view of requiring
more userspace->kernel->userspace->kernel->[...] trips to do discovery
every time, just because we decided not to work out a sensible
lifetime strategy to expose to userspace.

> This blew up with edid blob properties where SNA had one clever trick too
> many and thought that matching edid blob prop id means the edid is
> unchanged. But since we remove the old blob before we add the new one
> you're pretty much guranteed to reuse the same slot.

Sure, if you're not paying attention to the defined lifetime, then
don't do any caching. But this is about _defining_ such a usable
lifetime that userspace can.

>>   - setting a mode current should hold a reference for as long as it's 
>> current,
>> e.g. if you create a magic user-supplied mode, set that on the CRTC and
>> then terminate the connection, the mode should still live on for handover
>> purposes
>
> I think we need much less: If your driver supports atomic (and hence
> userspace might be asking for the mode blob prop id) then that blob should
> survive as long as the mode is in use.

Which not only requires the most invasive of the changes anyway
(modulo those to crtc->mode, which can regardless be dropped), but
also a bunch of 'every time the state changes, go consult some
auxiliary property and potentially expire its lifetime'.

>>   - persistence of system-supplied (from-connector or from-CRTC) modes is not
>> important beyond their natural lifetime: if you pick a mode up from a
>> connector's probed list and then that connector disappears, setting that
>> mode is unlikely to be what you want, so failure because the mode no
>> longer exists is entirely acceptable
>
> Somewhat unordered, but here's what I think we need:
> - Subtyping blob properties is not needed, at least I can't think of a
>   use-case. It will result though in lots of duplicated code for
>   duplicated ref/unref functions and atomic prop handling.

When you say 'subtyping', do you mean what I've done with getblob?

> - Since we already have a getblob ioctl I think we should just extend the
>   existing drm_property_blob:

That was actually my initial implementation, but didn't like the
resulting reference tie-up between drm_display_mode and
drm_property_blob (aka drm_mode_modeinfo). I couldn't figure out a
really clean way to do it that didn't provably fall 

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

[Archit Taneja]

Hi Hai,

On 03/19/2015 02:35 AM, hali at codeaurora.org wrote:
> Hi Archit,
>
> Thanks for your comments. Please see my response for some comments below.
> Comments without response will be addressed in patch version 2. I will
> wait for other comments if any to push patch V2.
>
>>> +static int dsi_gpio_init(struct msm_dsi_host *msm_host)
>>> +{
>>> +   int ret;
>>> +
>>> +   msm_host->disp_en_gpio = devm_gpiod_get(_host->pdev->dev,
>>> +   "disp-enable");
>>> +   if (IS_ERR(msm_host->disp_en_gpio)) {
>>> +   pr_warn("%s: cannot get disp-enable-gpios %ld\n",
>>> +   __func__, PTR_ERR(msm_host->disp_en_gpio));
>>> +   msm_host->disp_en_gpio = NULL;
>>> +   }
>>> +   if (msm_host->disp_en_gpio) {
>>> +   ret = gpiod_direction_output(msm_host->disp_en_gpio, 0);
>>> +   if (ret) {
>>> +   pr_err("cannot set dir to disp-en-gpios %d\n", ret);
>>> +   return ret;
>>> +   }
>>> +   }
>>> +
>>> +   msm_host->te_gpio = devm_gpiod_get(_host->pdev->dev, "disp-te");
>>> +   if (IS_ERR(msm_host->te_gpio)) {
>>> +   pr_warn("%s: cannot get disp-te-gpios %ld\n",
>>> +   __func__, PTR_ERR(msm_host->te_gpio));
>>
>> Video mode panels won't have te_gpio, we could probably make this
>> pr_debug()
>>
>>> +   msm_host->te_gpio = NULL;
>>> +   }
>>> +
>>> +   if (msm_host->te_gpio) {
>>> +   ret = gpiod_direction_input(msm_host->te_gpio);
>>> +   if (ret) {
>>> +   pr_err("%s: cannot set dir to disp-te-gpios, %d\n",
>>> +   __func__, ret);
>>> +   return ret;
>>> +   }
>>> +   }
>>
>> These gpios currently need to be declared under the dsi DT node. Even if
>> these are controlled via the dsi host, the gpios should still come under
>> the panel DT node.
>>
>> We shout get the panel's of_node here and look for these.
>>
>
>>> +static void dsi_sw_reset(struct msm_dsi_host *msm_host)
>>> +{
>>> +   dsi_write(msm_host, REG_DSI_CLK_CTRL,
>>> +   DSI_CLK_CTRL_AHBS_HCLK_ON | DSI_CLK_CTRL_AHBM_SCLK_ON |
>>> +   DSI_CLK_CTRL_PCLK_ON | DSI_CLK_CTRL_DSICLK_ON |
>>> +   DSI_CLK_CTRL_BYTECLK_ON | DSI_CLK_CTRL_ESCCLK_ON |
>>> +   DSI_CLK_CTRL_FORCE_ON_DYN_AHBM_HCLK);
>>
>> The same 7 bits seem to be set elsewhere, maybe make this a macro
>> DSI_ENABLE_CLKS or something similar?
>>
>
>>> +int msm_dsi_host_init(struct msm_dsi *msm_dsi)
>>> +{
>>> +   struct msm_dsi_host *msm_host = NULL;
>>> +   struct platform_device *pdev = msm_dsi->pdev;
>>> +   int ret = 0;
>>> +
>>> +   msm_host = devm_kzalloc(>dev, sizeof(*msm_host), GFP_KERNEL);
>>> +   if (!msm_host) {
>>> +   pr_err("%s: FAILED: cannot alloc dsi host\n",
>>> +  __func__);
>>> +   ret = -ENOMEM;
>>> +   goto fail;
>>> +   }
>>> +
>>> +   ret = of_property_read_u32(pdev->dev.of_node,
>>> +   "cell-index", _host->id);
>>
>> retrieving the instance number of a peripheral via a DT property like
>> 'cell-index' has been debated quite a bit in the past. I suppose it's
>> not the best thing to do.
>>
>> However, since the DSI instances in MDSS aren't completely identical(one
>> acts a master and other slave in dual dsi mode), maybe we can get away
>> with having a property like "qcom,dsi-master;", and that can be further
>> used to identify whether this node is DSI_0 or DSI_1
>>
>
> 2 DSIs are not always master-slave mode. It is possible that a single
> panel is connected to any of the hosts, or 2 panels are controlled
> independently. If 'cell-index' is not allowed to specify the instance
> number, i would prefer to have a simple property like
> "qcom,dsi-host-index".

Okay, thanks for that clarification.

>
>>> +int msm_dsi_host_register(struct mipi_dsi_host *host, bool check_defer)
>>> +{
>>> +   struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
>>> +   struct device_node *node;
>>> +   int ret;
>>> +
>>> +   /* Register mipi dsi host */
>>> +   if (!msm_host->registered) {
>>> +   host->dev = _host->pdev->dev;
>>> +   host->ops = _host_ops;
>>> +   ret = mipi_dsi_host_register(host);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   msm_host->registered = true;
>>> +
>>> +   /* If the panel driver has not been probed after host register,
>>> +* we should defer the host's probe.
>>> +* It makes sure panel is connected when fbcon detects
>>> +* connector status and gets the proper display mode to
>>> +* create framebuffer.
>>> +*/
>>> +   if (check_defer) {
>>> +   node = of_parse_phandle(msm_host->pdev->dev.of_node,
>>> +   "qcom,panel", 0);
>>> +   if (node) {
>>> +   if (!of_drm_find_panel(node))
>>> + 

[Intel-gfx] [PATCH 01/21 v2] drm/i915: Adding drm helper function drm_plane_from_index().

[Konduru, Chandra]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel 
> Vetter
> Sent: Monday, March 23, 2015 2:33 AM
> To: Konduru, Chandra
> Cc: intel-gfx at lists.freedesktop.org; Conselvan De Oliveira, Ander; Vetter, 
> Daniel
> Subject: Re: [Intel-gfx] [PATCH 01/21 v2] drm/i915: Adding drm helper function
> drm_plane_from_index().
> 
> On Fri, Mar 20, 2015 at 05:04:22PM -0700, Chandra Konduru wrote:
> > Adding drm helper function to return plane pointer from index where
> > index is a returned by drm_plane_index.
> >
> > v2:
> > -avoided nested loop by adding loop count (Daniel)
> >
> > Signed-off-by: Chandra Konduru 
> 
> Sorry forgotten to mention this earlier, but any code touching drm core must 
> be
> cc'ed to dri-devel. Best to just add a Cc: line before the sob line so that 
> git send-
> email automatically picks it up every time.
> -Daniel

np, sure.
By the way, copied dri-devel.

> 
> > ---
> >  drivers/gpu/drm/drm_crtc.c |   22 ++
> >  include/drm/drm_crtc.h |1 +
> >  2 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 9f970c2..b6703f4 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1286,6 +1286,28 @@ unsigned int drm_plane_index(struct drm_plane
> > *plane)  EXPORT_SYMBOL(drm_plane_index);
> >
> >  /**
> > + * drm_plane_from_index - find the registered plane at an index
> > + * @idx: index of registered plane to find for
> > + *
> > + * Given a plane index, return the registered plane from DRM device's
> > + * list of planes with matching index.
> > + */
> > +struct drm_plane *
> > +drm_plane_from_index(struct drm_device *dev, int idx) {
> > +   struct drm_plane *plane;
> > +   unsigned int i = 0;
> > +
> > +   list_for_each_entry(plane, >mode_config.plane_list, head) {
> > +   if (i == idx)
> > +   return plane;
> > +   i++;
> > +   }
> > +   return NULL;
> > +}
> > +EXPORT_SYMBOL(drm_plane_from_index);
> > +
> > +/**
> >   * drm_plane_force_disable - Forcibly disable a plane
> >   * @plane: plane to disable
> >   *
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 7b5c661..6b30036 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -1264,6 +1264,7 @@ extern int drm_plane_init(struct drm_device *dev,
> >   bool is_primary);
> >  extern void drm_plane_cleanup(struct drm_plane *plane);  extern
> > unsigned int drm_plane_index(struct drm_plane *plane);
> > +extern struct drm_plane * drm_plane_from_index(struct drm_device
> > +*dev, int idx);
> >  extern void drm_plane_force_disable(struct drm_plane *plane);  extern
> > int drm_plane_check_pixel_format(const struct drm_plane *plane,
> > u32 format);
> > --
> > 1.7.9.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

[h...@codeaurora.org]

Hi Archit,

> Hi Hai,
>
> On 03/19/2015 02:35 AM, hali at codeaurora.org wrote:
>> Hi Archit,
>>
>> Thanks for your comments. Please see my response for some comments
>> below.
>> Comments without response will be addressed in patch version 2. I will
>> wait for other comments if any to push patch V2.
>>
 +static int dsi_gpio_init(struct msm_dsi_host *msm_host)
 +{
 +  int ret;
 +
 +  msm_host->disp_en_gpio = devm_gpiod_get(_host->pdev->dev,
 +  "disp-enable");
 +  if (IS_ERR(msm_host->disp_en_gpio)) {
 +  pr_warn("%s: cannot get disp-enable-gpios %ld\n",
 +  __func__, PTR_ERR(msm_host->disp_en_gpio));
 +  msm_host->disp_en_gpio = NULL;
 +  }
 +  if (msm_host->disp_en_gpio) {
 +  ret = gpiod_direction_output(msm_host->disp_en_gpio, 0);
 +  if (ret) {
 +  pr_err("cannot set dir to disp-en-gpios %d\n", ret);
 +  return ret;
 +  }
 +  }
 +
 +  msm_host->te_gpio = devm_gpiod_get(_host->pdev->dev, "disp-te");
 +  if (IS_ERR(msm_host->te_gpio)) {
 +  pr_warn("%s: cannot get disp-te-gpios %ld\n",
 +  __func__, PTR_ERR(msm_host->te_gpio));
>>>
>>> Video mode panels won't have te_gpio, we could probably make this
>>> pr_debug()
>>>
 +  msm_host->te_gpio = NULL;
 +  }
 +
 +  if (msm_host->te_gpio) {
 +  ret = gpiod_direction_input(msm_host->te_gpio);
 +  if (ret) {
 +  pr_err("%s: cannot set dir to disp-te-gpios, %d\n",
 +  __func__, ret);
 +  return ret;
 +  }
 +  }
>>>
>>> These gpios currently need to be declared under the dsi DT node. Even
>>> if
>>> these are controlled via the dsi host, the gpios should still come
>>> under
>>> the panel DT node.
>>>
>>> We shout get the panel's of_node here and look for these.
>>>
>>
 +static void dsi_sw_reset(struct msm_dsi_host *msm_host)
 +{
 +  dsi_write(msm_host, REG_DSI_CLK_CTRL,
 +  DSI_CLK_CTRL_AHBS_HCLK_ON | DSI_CLK_CTRL_AHBM_SCLK_ON |
 +  DSI_CLK_CTRL_PCLK_ON | DSI_CLK_CTRL_DSICLK_ON |
 +  DSI_CLK_CTRL_BYTECLK_ON | DSI_CLK_CTRL_ESCCLK_ON |
 +  DSI_CLK_CTRL_FORCE_ON_DYN_AHBM_HCLK);
>>>
>>> The same 7 bits seem to be set elsewhere, maybe make this a macro
>>> DSI_ENABLE_CLKS or something similar?
>>>
>>
 +int msm_dsi_host_init(struct msm_dsi *msm_dsi)
 +{
 +  struct msm_dsi_host *msm_host = NULL;
 +  struct platform_device *pdev = msm_dsi->pdev;
 +  int ret = 0;
 +
 +  msm_host = devm_kzalloc(>dev, sizeof(*msm_host), GFP_KERNEL);
 +  if (!msm_host) {
 +  pr_err("%s: FAILED: cannot alloc dsi host\n",
 + __func__);
 +  ret = -ENOMEM;
 +  goto fail;
 +  }
 +
 +  ret = of_property_read_u32(pdev->dev.of_node,
 +  "cell-index", _host->id);
>>>
>>> retrieving the instance number of a peripheral via a DT property like
>>> 'cell-index' has been debated quite a bit in the past. I suppose it's
>>> not the best thing to do.
>>>
>>> However, since the DSI instances in MDSS aren't completely
>>> identical(one
>>> acts a master and other slave in dual dsi mode), maybe we can get away
>>> with having a property like "qcom,dsi-master;", and that can be further
>>> used to identify whether this node is DSI_0 or DSI_1
>>>
>>
>> 2 DSIs are not always master-slave mode. It is possible that a single
>> panel is connected to any of the hosts, or 2 panels are controlled
>> independently. If 'cell-index' is not allowed to specify the instance
>> number, i would prefer to have a simple property like
>> "qcom,dsi-host-index".
>
> Okay, thanks for that clarification.
>
>>
 +int msm_dsi_host_register(struct mipi_dsi_host *host, bool
 check_defer)
 +{
 +  struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
 +  struct device_node *node;
 +  int ret;
 +
 +  /* Register mipi dsi host */
 +  if (!msm_host->registered) {
 +  host->dev = _host->pdev->dev;
 +  host->ops = _host_ops;
 +  ret = mipi_dsi_host_register(host);
 +  if (ret)
 +  return ret;
 +
 +  msm_host->registered = true;
 +
 +  /* If the panel driver has not been probed after host register,
 +   * we should defer the host's probe.
 +   * It makes sure panel is connected when fbcon detects
 +   * connector status and gets the proper display mode to
 +   * create framebuffer.
 +   */
 +  if (check_defer) {
 +  node = of_parse_phandle(msm_host->pdev->dev.of_node,
 +  "qcom,panel", 0);
 +  if (node) 

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

[Archit Taneja]

Hi Stephane,

On 03/14/2015 01:19 AM, Stephane Viau wrote:
> 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,

msm8x16 would require a flush_hw_mask too, it should be 0x32a59 if I'm 
not wrong. Could you please add it for the next revision, or as a part 
of the 8x16 hw cfg patch?

Thanks,
Archit

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

[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.

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

https://bugzilla.kernel.org/show_bug.cgi?id=85421

EmanueL Czirai  changed:

   What|Removed |Added

 CC||emanueLczirai at cryptoLab.net

--- Comment #33 from EmanueL Czirai  ---
Created attachment 171791
  --> https://bugzilla.kernel.org/attachment.cgi?id=171791=edit
output of: sudo journalctl -b -1 --all --no-pager

Hi. I am getting something similar and I think it may be reproducible. Since I
upgraded to kernel 4 and also upgraded to:
libdrm-git (2.4.60.17.g8dff7a0-1)
xf86-video-ati-git (7.5.0.r34.g6291baa-1
mesa-dri-git 10.6.0_devel.68990-1  (i don't know what commit, but it's from 1-2
days ago, currently recompiling with latest commit to retry)
mesa-git 10.6.0_devel.68990-1
mesa-libgl-git 10.6.0_devel.68990-1
mesa-vaapi-git 10.6.0_devel.68990-1
mesa-vdpau-git 10.6.0_devel.68990-1
opencl-mesa-git 10.6.0_devel.68990-1


I got one random screen freeze(no blanking though) and system was locked up
while viewing a youtube video in chromium and using the volume buttons.
(nothing in the logs, probably because the system froze)

And this one which is probably reproducible, the next day, I plugged in my
webcam, and as soon as vlc was attempting to display it (even though it looked
like a black picture)  screen froze, then blacked the screen (can't remember if
with backlight or not) and then I unplugged the webcam before I
shutdown(pressed power button once after Ctrl+Alt+F2 to switch to a non-gfx
virtual terminal console) and thus see the log on next boot(journalctl -b -1)

Mar 23 15:06:15 manji kernel: radeon :00:01.0: ring 0 stalled for more than
10483msec
Mar 23 15:06:15 manji kernel: radeon :00:01.0: GPU lockup (current fence id
0x00012c15 last fence 
id 0x00012cdc on ring 0)

(full log included in attachment)
the above messages are the beginning of when it got blank

I don't know if this is a new issue because I haven't tried my webcam for at
least 1-2 months before this. But I've only recently(1-2days) upgraded to
kernel 4, from 3.19.

apparently after updating mesa(to try next) the new version is
10.6.0_devel.67962-1 but the old one(with the above error) was
10.6.0_devel.68990-1
using manjaro linux.
brb

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

[git pull] drm fixes

[Josh Boyer]

On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer  
wrote:



>> Xi Ruoyao (1):
>>   drm/i915: Ensure plane->state->fb stays in sync with plane->fb

Turns out to be that commit.

git bisect start 'drivers/gpu/drm/i915/'
# good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
# bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
# bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
plane->state->fb stays in sync with plane->fb
git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
# first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
drm/i915: Ensure plane->state->fb stays in sync with plane->fb

Doing a straight revert on top of 4.0-rc5 makes things work again,
albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
there.

josh

> I have a machine that no longer boots in a headless manner with -rc5.
> It's an Celeron based NUC device.  I blacklisted the i915 driver and
> it boots fine, then I ran insmod manually and got the backtrace below.
> This machine only has HDMI output on it.  If I have it connected (even
> if the monitor is set to display some other input) it will boot fine,
> but the backtrace is still present.  I'm going to guess the machine
> "hangs" in headless because X causes some further issues in the
> headless case.
>
> Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:
>
> [  +0.39] WARNING: CPU: 0 PID: 63 at
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> [i915]()
> [  +0.02] WARN_ON(obj->frontbuffer_bits)
>
> which is what I thought one of these commits was supposed to fix.  I
> don't see that in -rc5, but then we have these other issues.
>
> josh
>
> Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:
>
> [  +0.063764] vgaarb: device changed decodes:
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [  +0.007099] [ cut here ]
> [  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
> [  +0.03] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> 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_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [  +0.46]  r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [  +0.51] CPU: 1 PID: 1486 Comm: insmod Not tainted
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [  +0.04] Hardware name:
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [  +0.03]   ee312e2f 8800b7e03688
> 8177ac09
> [  +0.04]    8800b7e036c8
> 8109c78a
> [  +0.04]  8800b7e036b8 880234b46d80 880228ef4f00
> 88021a54
> [  +0.05] Call Trace:
> [  +0.09]  [] dump_stack+0x45/0x57
> [  +0.06]  [] warn_slowpath_common+0x8a/0xc0
> [  +0.04]  [] warn_slowpath_null+0x1a/0x20
> 

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #43 from Alex Deucher  ---
fix is upstream:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a17d4996e051e78d164989b894608cf37cd5110b

-- 
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/20150323/fb5edc55/attachment.html>

[PATCH] gpu: ipu-v3: limit pixel clock divider to 8-bits

[Philipp Zabel]

The DI pixel clock divider bit field is only 8 bits wide for the
integer part, so limit the divider to the 1...255 interval before
deciding whether the internal clock can be used and before writing
to the register.

Reported-by: Felix Mellmann 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-di.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index 6607cc8..247871f 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -519,8 +519,7 @@ static void ipu_di_config_clock(struct ipu_di *di,

in_rate = clk_get_rate(clk);
div = DIV_ROUND_CLOSEST(in_rate, sig->mode.pixelclock);
-   if (div == 0)
-   div = 1;
+   div = clamp(div, 1U, 255U);

clkgen0 = div << 4;
}
@@ -537,8 +536,7 @@ static void ipu_di_config_clock(struct ipu_di *di,

clkrate = clk_get_rate(di->clk_ipu);
div = DIV_ROUND_CLOSEST(clkrate, sig->mode.pixelclock);
-   if (div == 0)
-   div = 1;
+   div = clamp(div, 1U, 255U);
rate = clkrate / div;

error = rate / (sig->mode.pixelclock / 1000);
@@ -561,8 +559,7 @@ static void ipu_di_config_clock(struct ipu_di *di,

in_rate = clk_get_rate(clk);
div = DIV_ROUND_CLOSEST(in_rate, sig->mode.pixelclock);
-   if (div == 0)
-   div = 1;
+   div = clamp(div, 1U, 255U);

clkgen0 = div << 4;
}
-- 
2.1.4

[trivial PATCH] MAINTAINERS: Remove DRM DRIVERS FOR RENESAS pattern

[Joe Perches]

commit 2378ad1228d2 ("drm: rcar-du: Remove platform data support")
removed the file, remove the pattern.

Signed-off-by: Joe Perches 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 78195d3..47aaa52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3405,7 +3405,6 @@ T:git git://people.freedesktop.org/~airlied/linux
 S: Supported
 F: drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
-F: include/linux/platform_data/rcar-du.h
 F: include/linux/platform_data/shmob_drm.h

 DSBR100 USB FM RADIO DRIVER

[patch] drm/nouveau/fb: remove unneeded an condition

[Dan Carpenter]

We checked "ver" and "ramcfg.size" before and they haven't changed so
static checkers complain when we test them again here.  "rammap.data"
isn't be NULL so "ramcfg.data" is also not NULL so there is no need to
check.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
index de9f395..e465635 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
@@ -157,10 +157,6 @@ gf100_ram_calc(struct nvkm_fb *pfb, u32 freq)
}

ramcfg.data = rammap.data + rammap.size + (strap * ramcfg.size);
-   if (!ramcfg.data || ver != 0x10 || ramcfg.size < 0x0e) {
-   nv_error(pfb, "invalid/missing ramcfg entry\n");
-   return -EINVAL;
-   }

/* lookup memory timings, if bios says they're present */
strap = nv_ro08(bios, ramcfg.data + 0x01);

[PATCH] gpu: ipu-v3: turns out the IPU can only downsize 4:1

[Philipp Zabel]

The value for downsizing 8:1 is marked as reserved in the technical reference
manual and the documentation states downsizing capability up to 4:1 only.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-ic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index ad75588..1dcb96c 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -297,8 +297,8 @@ static int calc_resize_coeffs(struct ipu_ic *ic,
return -EINVAL;
}

-   /* Cannot downsize more than 8:1 */
-   if ((out_size << 3) < in_size) {
+   /* Cannot downsize more than 4:1 */
+   if ((out_size << 2) < in_size) {
dev_err(ipu->dev, "Unsupported downsize\n");
return -EINVAL;
}
-- 
2.1.4

[git pull] drm fixes

[Josh Boyer]

On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie  wrote:
>
> Hi Linus,
>
> a bunch of fixes across drivers,
> radeon: disable two ended allocation for now, it breaks some stuff
> amdkfd: misc fixes
> nouveau: fix irq loop problem, add basic support for GM206 (new hw)
> i915: fix some WARNs people were seeing
> exynos: fix some iommu interactions causing boot failures
>
> In other news I've some problem with my git tree and git request-pull
> [airlied at dreadlord-bne-redhat-com linux]$ git request-pull linus/master 
> origin
> warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at 
> origin
> warn: Are you sure you pushed 'HEAD' there?
>
> is happening when I just had my branch on drm-fixes, I've made it master
> to generate this pull request so the branch name isn't missing, this
> might be due to my attempt to remove my own master branch, using
> git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
> week I suppose.



>
> Damien Lespiau (1):
>   drm/i915: Make sure the primary plane is enabled before reading out the 
> fb state

> Xi Ruoyao (1):
>   drm/i915: Ensure plane->state->fb stays in sync with plane->fb

I have a machine that no longer boots in a headless manner with -rc5.
It's an Celeron based NUC device.  I blacklisted the i915 driver and
it boots fine, then I ran insmod manually and got the backtrace below.
This machine only has HDMI output on it.  If I have it connected (even
if the monitor is set to display some other input) it will boot fine,
but the backtrace is still present.  I'm going to guess the machine
"hangs" in headless because X causes some further issues in the
headless case.

Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:

[  +0.39] WARNING: CPU: 0 PID: 63 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[  +0.02] WARN_ON(obj->frontbuffer_bits)

which is what I thought one of these commits was supposed to fix.  I
don't see that in -rc5, but then we have these other issues.

josh

Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:

[  +0.063764] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  +0.007099] [ cut here ]
[  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[  +0.03] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
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_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[  +0.46]  r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[  +0.51] CPU: 1 PID: 1486 Comm: insmod Not tainted
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[  +0.04] Hardware name:
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[  +0.03]   ee312e2f 8800b7e03688
8177ac09
[  +0.04]    8800b7e036c8
8109c78a
[  +0.04]  8800b7e036b8 880234b46d80 880228ef4f00
88021a54
[  +0.05] Call Trace:
[  +0.09]  [] dump_stack+0x45/0x57
[  +0.06]  [] 

[PATCH 2/2] drm/radeon: programm the VCE fw BAR as well

[Christian König]

From: Christian König 

Otherwise the VCE firmware needs to be in the first 256MB of VRAM.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/cikd.h | 1 +
 drivers/gpu/drm/radeon/vce_v2_0.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index c648e19..243a36c 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -2129,6 +2129,7 @@
 #define VCE_UENC_REG_CLOCK_GATING  0x207c0
 #define VCE_SYS_INT_EN 0x21300
 #  define VCE_SYS_INT_TRAP_INTERRUPT_EN(1 << 3)
+#define VCE_LMI_VCPU_CACHE_40BIT_BAR   0x2145c
 #define VCE_LMI_CTRL2  0x21474
 #define VCE_LMI_CTRL   0x21498
 #define VCE_LMI_VM_CTRL0x214a0
diff --git a/drivers/gpu/drm/radeon/vce_v2_0.c 
b/drivers/gpu/drm/radeon/vce_v2_0.c
index 1ac7bb8..fbbe78f 100644
--- a/drivers/gpu/drm/radeon/vce_v2_0.c
+++ b/drivers/gpu/drm/radeon/vce_v2_0.c
@@ -156,6 +156,9 @@ int vce_v2_0_resume(struct radeon_device *rdev)
WREG32(VCE_LMI_SWAP_CNTL1, 0);
WREG32(VCE_LMI_VM_CTRL, 0);

+   WREG32(VCE_LMI_VCPU_CACHE_40BIT_BAR, addr >> 8);
+
+   addr &= 0xff;
size = RADEON_GPU_PAGE_ALIGN(rdev->vce_fw->size);
WREG32(VCE_VCPU_CACHE_OFFSET0, addr & 0x7fff);
WREG32(VCE_VCPU_CACHE_SIZE0, size);
-- 
1.9.1

[PATCH 1/2] drm/radeon: always dump the ring content if it's available

[Christian König]

From: Christian König 

Dumping is still possible if a ring isn't ready, only when it
isn't allocated at all we need to abort here.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index 2456f69..8c78723 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -495,7 +495,7 @@ static int radeon_debugfs_ring_info(struct seq_file *m, 
void *data)
seq_printf(m, "%u free dwords in ring\n", ring->ring_free_dw);
seq_printf(m, "%u dwords in ring\n", count);

-   if (!ring->ready)
+   if (!ring->ring)
return 0;

/* print 8 dw before current rptr as often it's the last executed
-- 
1.9.1

[PATCH 1/2] drm/radeon: always dump the ring content if it's available

[Alex Deucher]

On Mon, Mar 23, 2015 at 6:32 AM, Christian König
 wrote:
> From: Christian König 
>
> Dumping is still possible if a ring isn't ready, only when it
> isn't allocated at all we need to abort here.
>
> Signed-off-by: Christian König 

Applied the series.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 2456f69..8c78723 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -495,7 +495,7 @@ static int radeon_debugfs_ring_info(struct seq_file *m, 
> void *data)
> seq_printf(m, "%u free dwords in ring\n", ring->ring_free_dw);
> seq_printf(m, "%u dwords in ring\n", count);
>
> -   if (!ring->ready)
> +   if (!ring->ring)
> return 0;
>
> /* print 8 dw before current rptr as often it's the last executed
> --
> 1.9.1
>

[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent

[Emil Velikov]

Hi Tobias,
On 22/03/15 16:29, Tobias Jakobi wrote:
> Hello Emil,
> Emil Velikov wrote:
>> I fear we are not (yet) allowed to do either of these changes.
>>
>> The exynos/exynos_drm.h header is (supposed to) be in sync/come from the
>> kernel. And changes here are to be reflected only when the corresponding
>> patch lands in drm-next (as per RELEASING).
> the point here is, that the current header in libdrm in _not_ in sync
> with the one in the kernel. It's hopelessly outdated, but mainly because
> exynos/libdrm doesn't use any new functionality provided by some update.
> 
> Here's the current kernel header:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/uapi/drm/exynos_drm.h
> 
> The event stuff has been there since 2012:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/drm/exynos_drm.h?id=d7f1642c90ab5eb2d7c48af0581c993094f97e1a
> 
> The only reason why I haven't added the IPP things, is because I don't
> intend to work on this for the moment.
> 
Hmmm good point. Seems like the changes went in before I started
following exynos development. If it's in an upstream kernel, then it's
save to land in libdrm. Objection withdrawn.

I have an idea how we can get things back into shape (wrt headers being
out if sync) - I will propose/post a solution shortly.

>> Wrt extending the current drmEventContext, I'm not sure that adding
>> device specific changes to it are allowed.
> Why shouldn't it? Isn't drmHandleEvent supposed to handle all kinds of
> DRM events that the kernel produces?
> 
Bth I'm not familiar with the code in question, although a quick grep
indicates that libdrm does not contain any driver specific information.
That is aside from the include/drm headers, although they are not part
of the library or its interface.

Maybe some of the more experienced devs can share some light ?

Thanks
Emil

commit 7ce42ae67c49204c0b2252edd06f7920e0a51037 cause various errors

[Jani Nikula]

On Sun, 22 Mar 2015, François Valenduc  wrote:
> It seems commit 7ce42ae67c49204c0b2252edd06f7920e0a51037 causes
> several errors.

It seems I don't have this commit. Which tree is this?

I also admit to being pretty bad at associating commit ids with the
actual commits, especially so for commit ids I don't have. It would be
helpful to include the title of the commit too. ;)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

My GSoC proposal needs help :-)

[John Hunter]

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/20150323/e7b2679a/attachment-0001.html>

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

[Andrzej Hajda]

On 03/20/2015 06:15 AM, Hyungwon Hwang wrote:
> Dear Andrej,
>
> On Thu, 19 Mar 2015 10:32:10 +0100
> Andrzej Hajda  wrote:
>
>> On 03/19/2015 02:18 AM, Hyungwon Hwang wrote:
>>> Dear Daniel,
>>>
>>> On Thu, 19 Mar 2015 01:13:21 +
>>> Daniel Stone  wrote:
>>>
 Hi Hyungwon,

 On 19 March 2015 at 01:02, Hyungwon Hwang
  wrote:
>>> +   /*
>>> +* The input PLL clock for MIPI DSI in Exynos5433 seems
>>> to be fixed
>>> +* by OSC CLK.
>>> +*/
>>> +   fin = 24 * MHZ;
>> Er, is this always true on other platforms as well? Shouldn't
>> this be a part of the DeviceTree description?
> I forgot to change the comment in development. Finally it is found
> that all exynos mipi dsi's fin is OSC clk which is 24 MHz. So I
> will remove the comment, but remain the code as it is.
 Fair enough. Should pll_clk be removed from the DT description
 then, if it's fixed to the oscillator?
>>> Yes. It is redundant to represent pll_clk in DT, and it should be
>>> removed.
>> Why do you think OSC clk determines value of pll_clk?
>> pll_clk is mapped to SCLK_MIPI[01] or SCLK_DSIM0 gate with few
>> dividers and muxes above. So at least in theory it can differ from
>> osc clk. Additionally this gate should be enabled so you cannot just
>> remove it from DT.
>>
>> Regards
>> Andrzej
> As I found, pll clk is not SCLK_MIPI[01] but OSC CLK. SCLK_DSIM0 must
> be controlled in this driver as it has been, as a gate clock of MIPI
> DSI block, but not as a pll clk. SCLK_DSIM0 is not the input
> clock of MIPI DPHY which provides fin in this code. So clock setting
> and getting code was wrong, and must be removed.
>
> OSC CLK is not soc-depedendant but board-dependant, even though I have
> not seen any board which does not use OSC CLK by 24 MHz. It must be
> parsed from board DT file, which in this case, we can use the value in
> pll_clk_rate (the variable name must be renamed also).
>
> Because ambiguous description in the technical document, I can be
> wrong. Please let me know if I do not understand something. Thanks for
> your comment.

After some digging I agree that documentation is quite confusing and
current code could be wrong. Anyway I wonder if it wouldn't be better
to explicitly provide input clock for DSIM, or more precisely for its PLL
instead of hardcoding 24MHz into the driver.

Another thing that bothers me is relation of DPHY_PLL in clock controller to
MIPI_DPHY in Exynos7420. There are two clocks used by MIPI_DPHY:
- "Ref Clock" pinned to SCLK_MIPIDPHY_M4 connected to OSCCLK,
- "PHY Clock" pinned to I_FOUT_DPHY_PLL connected to DPHY_PLL,

The first clock seems to be your osc clock, but what is the role of the
2nd one?

Regards
Andrzej

> Best regards,
> Hyungwon Hwang
>
> Thanks for your review. I will send it again with the changes you
> suggested.
 Thanks very much!

 Cheers,
 Daniel
>>> Best regards,
>>> Hyungwon Hwang
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> devicetree" in the body of a message to
>>> majordomo-u79uwXL29TY76Z2rM5mHXA at public.gmane.org More majordomo
>>> info at  http://vger.kernel.org/majordomo-info.html
>>>

[RFC PATCH 00/37] Modesetting for atomic modesetting

[Daniel Vetter]

On Thu, Mar 19, 2015 at 04:32:36AM +, Daniel Stone wrote:
> Well, that escalated quickly.
> 
> I've been looking at adding modesetting support to the atomic ioctl, and this
> is what I've ended up with so far. It's definitely not perfect, but given how
> out of hand it's got at the moment, I wanted to send this out as an RFC before
> I spent too long polishing it up.
> 
> This series ends up touching pretty much all the drivers, by virtue of turning
> crtc->mode (in particular) into both a const and a pointer.

Ok this is quite a bit a different beast than what I expected. I think
it's way too intrusive for drivers to land quickly, and there's a big
depency chain linking everything. I think we need something much simpler.

> The reasoning behind this is that currently, we just treat modes as unboxed
> data to shovel around. With atomic modesetting, and user-supplied modes, we
> want to do better here. Whilst sketching out userspace/compositor
> requirements, I came up with the following invariants, which necessitated
> turning modes into a refcounted, immutable, type:
>   - modes can come from one of three sources: connector list, current
> mode, userspace-created
>   - as far as possible, modes should be relateable to their source, e.g. if
> Plymouth pulls a particular mode from the encoder, and you pick up on that
> mode as part of current configuration during handover, you should be able
> to work backwards to where Plymouth sourced it, i.e. the encoder list

With legacy setcrtc we already lose this information and thus far no one
seems to have cared. And I don't see the use-case since simply comparing
it to sources works well enough, in case you want to know where a mode is
from.

>   - userspace should be able to tell the current status by looking at the IDs
> returned by property queries, rather than having to pull the entire mode
> out: if we make them do that, they won't bother minimising the deltas and
> will just dump the full state in every time, and that makes debugging the
> entire thing that much harder

That doesn't work since idr eagerly reuses ids. Just by looking at the id
you can't tell whether it's the same object or a new one accidentally
reusing the same id slot. You always have to re-read the blob property too
to reconstruct state.

This blew up with edid blob properties where SNA had one clever trick too
many and thought that matching edid blob prop id means the edid is
unchanged. But since we remove the old blob before we add the new one
you're pretty much guranteed to reuse the same slot.

>   - setting a mode current should hold a reference for as long as it's 
> current,
> e.g. if you create a magic user-supplied mode, set that on the CRTC and
> then terminate the connection, the mode should still live on for handover
> purposes

I think we need much less: If your driver supports atomic (and hence
userspace might be asking for the mode blob prop id) then that blob should
survive as long as the mode is in use.

>   - persistence of system-supplied (from-connector or from-CRTC) modes is not
> important beyond their natural lifetime: if you pick a mode up from a
> connector's probed list and then that connector disappears, setting that
> mode is unlikely to be what you want, so failure because the mode no
> longer exists is entirely acceptable

Somewhat unordered, but here's what I think we need:
- Subtyping blob properties is not needed, at least I can't think of a
  use-case. It will result though in lots of duplicated code for
  duplicated ref/unref functions and atomic prop handling.

- Since we already have a getblob ioctl I think we should just extend the
  existing drm_property_blob:

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adc9ea5acf02..9845b634d2d3 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -217,6 +217,7 @@ struct drm_framebuffer {

 struct drm_property_blob {
struct drm_mode_object base;
+   struct kref refcount;
struct list_head head;
size_t length;
unsigned char data[];

  Plus ofc changing drm_property_create/destroy_blob into ref/unref
  functions. And doing the same weak reference trick for idrs as we're
  using for framebuffers now.

  For mode properties the data contained would be struct drm_mode_modeinfo
  (i.e. the ABI struct we already use for the setcrtc/getconnector ioctls,
  not the internal one).

- Imo requiring all the legacy users to be converted to pointers isn't
  needed. crtc->mode/hwmode are deprecated for atomic drivers. Not that I
  don't think doing this isn't useful, I just think it's not needed to
  have a minimal atomic mode blob support.

  Aside: We don't even need to convert mode structs to pointers if we
  embedded the kref into the mode - I've done similar horrible conversion
  tricks with framebuffers, where drivers tend to embed the static fbdev
  framebuffer into the fbdev emulation 

[PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[Daniel Vetter]

On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
> We have grown a number of different implementations of
> DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
> kernel.h so that it can be reused.
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: Darrick J. Wong 
> Cc: Guenter Roeck 
> Cc: Andrew Morton 
> Signed-off-by: Javi Merino 

Acked-by: Daniel Vetter 

And preemptive ack for the next version with the includes at different
places.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_drv.h |  4 +---
>  include/linux/kernel.h   | 11 +++
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index eef79ccd0b7c..346e28fdd7dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "i915_drv.h"
>  #include 
> @@ -36,9 +37,6 @@
>  #include 
>  #include 
>  
> -#define DIV_ROUND_CLOSEST_ULL(ll, d) \
> -({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
> -
>  /**
>   * _wait_for - magic (register) wait macro
>   *
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index d6d630d31ef3..f7d744e9d275 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -103,6 +103,17 @@
>   (((__x) - ((__d) / 2)) / (__d));\
>  }\
>  )
> +/*
> + * Same as above but for u64 dividends.  divisor must be a 32-bit
> + * number.
> + */
> +#define DIV_ROUND_CLOSEST_ULL(x, divisor)(   \
> +{\
> + unsigned long long _tmp = (x) + (divisor) / 2;  \
> + do_div(_tmp, divisor);  \
> + _tmp;   \
> +}\
> +)
>  
>  /*
>   * Multiplies an integer by a fraction, while avoiding unnecessary
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2015-03-13-rebased:
- EU count report param for gen9+ (Jeff McGee)
- piles of pll/wm/... fixes for chv, finally out of preliminary hw support
  (Ville, Vijay)
- gen9 rps support from Akash
- more work to move towards atomic from Matt, Ander and others
- runtime pm support for skl (Damien)
- edp1.4 intermediate link clock support (Sonika)
- use frontbuffer tracking for fbc (Paulo)
- remove ilk rc6 (John Harrison)
- a bunch of smaller things and fixes all over

Includes backmerge because git rerere couldn't keep up any more. And full
rebase because at first I accidentally based this on top of the broken
merge and didn't notice (since we pull in drm-next too for -nightly).

Cheers, Daniel


The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127:

  Merge tag 'topic/drm-misc-2015-03-10' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2015-03-11 12:15:06 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-03-13-merge

for you to fetch changes up to 0f9e9cd61f46c07246e30871fd638ffeaca3c576:

  Merge tag 'drm-intel-fixes-2015-03-19' into drm-intel-next (2015-03-20 
11:44:34 +0100)


Aaro Koskinen (1):
  ARM: OMAP: enable TWL4030_USB in omap2plus_defconfig

Ahmed S. Darwish (2):
  can: kvaser_usb: Avoid double free on URB submission failures
  can: kvaser_usb: Read all messages in a bulk-in URB buffer

Akash Goel (11):
  drm/i915/skl: Added new macros
  drm/i915/skl: Updated intel_gpu_freq() and intel_freq_opcode()
  drm/i915/skl: Updated the gen6_init_rps_frequencies function
  drm/i915/skl: Updated the gen6_set_rps function
  drm/i915/skl: Restructured the gen6_set_rps_thresholds function
  drm/i915/skl: Updated the gen6_rps_limits function
  drm/i915/skl: Updated the gen9_enable_rps function
  drm/i915/skl: Updated the act_freq_mhz_show sysfs function
  drm/i915/skl: Updated the i915_frequency_info debugfs function
  drm/i915/skl: Enabling processing of Turbo interrupts
  drm/i915/skl: Enable the RPS interrupts programming

Al Viro (8):
  new helper: dup_iter()
  move iov_iter.c from mm/ to lib/
  gadget/function/f_fs.c: close leaks
  gadget/function/f_fs.c: use put iov_iter into io_data
  gadget/function/f_fs.c: switch to ->{read,write}_iter()
  gadgetfs: use-after-free in ->aio_read()
  gadget: switch ep_io_operations to ->read_iter/->write_iter
  gadgetfs: get rid of flipping ->f_op in ep_config()

Alan Stern (1):
  gadgetfs: really get rid of switching ->f_op

Alexander Drozdov (1):
  ipv4: ip_check_defrag should not assume that skb_network_offset is zero

Alexander Stein (1):
  ARM: at91/dt: at91sam9263: Fixup sram1 device tree node

Alexander Sverdlin (1):
  spi: pl022: Fix race in giveback() leading to driver lock-up

Alexandre Belloni (4):
  ARM: at91: pm: fix at91rm9200 standby
  ARM: at91: pm: fix SRAM allocation
  ARM: at91/defconfig: add at91rm9200 ethernet support
  ARM: at91: debug: fix non MMU debug

Alexey Brodkin (1):
  stmmac: check IRQ availability early on probe

Alexey Kardashevskiy (1):
  vfio-pci: Add missing break to enable VFIO_PCI_ERR_IRQ_INDEX

Ameen Ali (1):
  s390/dcss: array index 'i' is used before limits check.

Ander Conselvan de Oliveira (4):
  drm/i915: Set crtc backpointer when duplicating crtc state
  drm/i915: Add a for_each_intel_connector macro
  drm/i915: Improve staged config logging
  drm/i915: Simplify the way BC bifurcation state consistency is kept

Andrey Ryabinin (2):
  kasan, module, vmalloc: rework shadow allocation for modules
  kasan, module: move MODULE_ALIGN macro into 

Andrzej Hajda (1):
  ARM: dts: add display power domain for exynos5250

Andy Shevchenko (3):
  spi: dw-pci: correct number of chip selects
  spi: dw: revisit FIFO size detection again
  spi: dw-mid: avoid potential NULL dereference

Anthony Harivel (1):
  ARM: at91/defconfig: remove CONFIG_SYSFS_DEPRECATED

Ard Biesheuvel (2):
  efi/arm64: use UEFI for system reset and poweroff
  arm64: put __boot_cpu_mode label after alignment instead of before

Arnd Bergmann (11):
  Input: sun4i-ts - add thermal driver dependency
  Merge tag 'samsung-fixes-dt' of 
git://git.kernel.org/.../kgene/linux-samsung into fixes
  Merge tag 'samsung-fixes-1' of 
git://git.kernel.org/.../kgene/linux-samsung into fixes
  Merge tag 'at91-fixes' of git://git.kernel.org/.../nferre/linux-at91 into 
fixes
  ARM: fix typos in smc91x platform data
  of: unittest: fix I2C dependency
  Merge tag 'socfpga_fixes_for_v4.0' of 
git://git.rocketboards.org/linux-socfpga-next into fixes
  Merge tag 'at91-fixes2' of git://git.kernel.org/.../nferre/linux-at91 
into fixes
  Merge tag 'fixes-v4.0-rc2' of 

[PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[Jeff Epler]

On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
> +/*
> + * Same as above but for u64 dividends.  divisor must be a 32-bit
> + * number.
> + */
> +#define DIV_ROUND_CLOSEST_ULL(x, divisor)(   \
> +{\
> + unsigned long long _tmp = (x) + (divisor) / 2;  \
> + do_div(_tmp, divisor);  \
> + _tmp;   \
> +}\
> +)

The macro evaluates 'divisor' twice.

Jeff

[Bug 89431] Monitor is deactivated after DPMS activates

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

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

--- Comment #10 from rob at emanuele.us ---
As an additional data point, monitor power-save seems to work correctly during
the login screen, LightDM.

-- 
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/20150323/d6636341/attachment.html>

[Bug 89699] Regression in 10.5.1 causes flickering/artifacting in a particular video game

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

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

--- Comment #5 from Michel Dänzer  ---
(In reply to andre35822 from comment #4)
> I found this https://wiki.archlinux.org/index.php/Bisecting_bugs essentially
> do I just follow these steps?

Yes.

-- 
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/20150323/c1cc53d4/attachment.html>

[Bug 89707] WebGL GLSL conformance test: sin_001_to_006.html causing system freeze

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

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

--- Comment #2 from Michel Dänzer  ---
Can you bisect Mesa?

-- 
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/20150323/506d4161/attachment.html>

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

[Carsten Emde]

Hi Michel,

 [..]
 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.
>>
>> Thanks a lot. I have applied these patches to a number of systems:
>> # quilt applied | tail -7
>> patches/drm-radeon-do-a-posting-read-in-r100_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-rs600_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-r600_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-evergreen_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-si_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-cik_set_irq.patch
>> patches/drm-radeon-fix-wait-to-actually-occur-after-the-signaling-callback.patch
>>
>>
>>   The graphic boards still crash and freeze the screen, but in contrast
>> to the earlier situation the systems remain accessible, and the X
>> Window server can be restarted after the offensive programs are
>> removed. The crashes were reliably triggered by
>> - gltestperf
>>or
>> - x11perf -repeat 3 -subs 25 -time 2 -rect10
This is not entirely correct, since gltestperf does not reliably crash
the graphics controller. However, "x11perf -repeat 3 -subs 25 -time 2
-rect10" always does a reliable job to trigger the crash.

>> but the crashes also occur several times per day during normal work
>> such as browsing the Internet or writing a text document. If you wish
>> me to provide additional diagnostic information such as running test
>> programs while the graphic boards are unresponsive, I certainly can do
>> that.
>
> Does it also happen with a kernel built from a current drm-fixes tree?
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes
No. Apparently, you need full preemption to expose the problem.

The following list contains the results whether the command "x11perf
-repeat 3 -subs 25 -time 2 -rect10" freezes the Radeon board under test
(Radeon HD 7970 XFS / R9 280X) or not:
linux-3.12.33-rt47   no
linux-3.14.34-rt32   no
linux-3.14.34-drm-3.16.7-rt32*   no
linux-3.18.7-rt1YES
linux-3.18.9-rt4YES
linux-3.18.9-rt5YES
linux-3.18.9-drm-3.16.7-rt5**no
linux-4.0.0-rc4  no
linux-drm-fixes  no
*DRM subsystem backported from linux-3.16.7 to linux-3.14.34-rt32.
**DRM subsystem ported from linux-3.16.7 to linux-3.18.9-rt5.

More observations:
If full function tracing is enabled (which makes the system about five
times slower), the graphics controller no longer freezes. With partial
function tracing such as "echo *drm* >set_ftrace_filter", the
controller still freezes. The trace then contains vblank interrupt
processing only, ioctls are no longer executed.

This is the location where the driver hangs:
[25104.509258] INFO: task Xorg.bin:16591 blocked for more than 120 seconds.
[25104.516322]   Not tainted 3.18.9-rt5 #2
[25104.520715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[25104.528853] Xorg.binD 8171ed90 0 16591  16239 
0x10400080
[25104.536102]  8800ba0bb8d8 0002 8800ba0bbfd8 
0006
[25104.536103]  dc08 880626d0dc08 8800ba0bbfd8 
dc08
[25104.536104]  88061b2cdcd0 880616d3a940 880035c1 
880616d3a940
[25104.559274] Call Trace:
[25104.561844]  [] schedule+0x34/0xa0
[25104.561846]  [] schedule_timeout+0x23c/0x2a0
[25104.561870]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[25104.561879]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[25104.561887]  [] 
radeon_fence_wait_seq_timeout.constprop.8+0x327/0x380 [radeon]
[25104.561889]  [] ? __wake_up_sync+0x20/0x20
[25104.561898]  [] radeon_fence_wait_any+0x57/0x70 
[radeon]
[25104.561914]  [] radeon_sa_bo_new+0x2af/0x4b0 [radeon]
[25104.561916]  [] ? debug_smp_processor_id+0x17/0x20
[25104.561918]  [] ? __kmalloc+0x8a/0x300
[25104.561932]  [] radeon_ib_get+0x37/0xe0 [radeon]
[25104.561943]  [] radeon_cs_ioctl+0x22e/0x860 [radeon]
[25104.561952]  [] drm_ioctl+0x197/0x670 [drm]
[25104.561954]  [] ? debug_smp_processor_id+0x17/0x20
[25104.561956]  [] ?