drm/atomic: add commit_planes_on_crtc helper

[Dan Carpenter]

Hello Maarten Lankhorst,

This is a semi-automatic email about new static checker warnings.

The patch 32975e952e85: "drm/atomic: add commit_planes_on_crtc 
helper" from May 19, 2015, leads to the following Smatch complaint:

drivers/gpu/drm/drm_atomic_helper.c:1244 
drm_atomic_helper_commit_planes_on_crtc()
 error: we previously assumed 'crtc_funcs' could be null (see line 1221)

drivers/gpu/drm/drm_atomic_helper.c
  1220  crtc_funcs = crtc->helper_private;
  1221  if (crtc_funcs && crtc_funcs->atomic_begin)
^^
Check.

  1222  crtc_funcs->atomic_begin(crtc);
  1223  
  1224  drm_for_each_plane_mask(plane, crtc->dev, plane_mask) {
  1225  struct drm_plane_state *old_plane_state =
  1226  drm_atomic_get_existing_plane_state(old_state, 
plane);
  1227  const struct drm_plane_helper_funcs *plane_funcs;
  1228  
  1229  plane_funcs = plane->helper_private;
  1230  
  1231  if (!old_plane_state || !plane_funcs)
  1232  continue;
  1233  
  1234  WARN_ON(plane->state->crtc && plane->state->crtc != 
crtc);
  1235  
  1236  if (drm_atomic_plane_disabling(plane, old_plane_state) 
&&
  1237  plane_funcs->atomic_disable)
  1238  plane_funcs->atomic_disable(plane, 
old_plane_state);
  1239  else if (plane->state->crtc ||
  1240   drm_atomic_plane_disabling(plane, 
old_plane_state))
  1241  plane_funcs->atomic_update(plane, 
old_plane_state);
  1242  }
  1243  
  1244  if (crtc_funcs->atomic_flush)
^^
Unchecked dereference.

  1245  crtc_funcs->atomic_flush(crtc);
  1246  }

regards,
dan carpenter

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #89 from Pär Forsling  ---
(In reply to Oliver Winker from comment #88)
> (In reply to r.andersen from comment #84)
> > ... and I should add
> > 
> > echo "50" > pwm1
> > 
> > also makes my computer hang.
> 
> Exactly the same on my HD7850 (see [1]) on kernel v4.0. 
> 
> Are there maybe hints how to debug this ?
 


Sorry, I have no debug hints. For what it's worth, I have a nearly identical
card and the same kernel version (see below), and both manual and automatic
modes works flawlessly.

$ uname -a
Linux wallace 4.0.0-1-pelle #1 SMP PREEMPT Thu Apr 23 20:32:42 CEST 2015 x86_64
GNU/Linux

$ sudo lspci -v
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Pitcairn PRO [Radeon HD 7850] (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device 2553
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at fe78 (64-bit, non-prefetchable) [size=256K]
I/O ports at b000 [size=256]
Expansion ROM at fe7c [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 
Capabilities: [150] Advanced Error Reporting
Capabilities: [270] #19
Capabilities: [2b0] Address Translation Service (ATS)
Capabilities: [2c0] #13
Capabilities: [2d0] #1b
Kernel driver in use: radeon
Kernel modules: radeon

-- 
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/20150520/2bc4535e/attachment.html>

[PATCH v2] drm/exynos: calculate vrefresh instead of use a fixed value

[Tobias Jakobi]

Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> for us so we can get the correct value instead of relying on fixed value
> defined in a macro. But if vrefresh is still zero we should fail the
> update.
Even with this we still need to consider crtc->state->adjusted_mode in
fimd_commit(), otherwise vrefresh computed by drm_mode_vrefresh() is
never actually used.


With best wishes,
Tobias


> Suggested-by: Daniel Stone 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9819fa6..ea7da0e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -42,7 +42,6 @@
>   * CPU Interface.
>   */
>  
> -#define FIMD_DEFAULT_FRAMERATE 60
>  #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>  
>  /* position control register for hardware window 0, 2 ~ 4.*/
> @@ -329,7 +328,9 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
>   struct drm_display_mode *adjusted_mode)
>  {
>   if (adjusted_mode->vrefresh == 0)
> - adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
> + adjusted_mode->vrefresh = drm_mode_vrefresh(mode);
> + if (adjusted_mode->vrefresh == 0)
> + return false;
>  
>   return true;
>  }
> 

[PATCH] drm: drop drm_property_unreference_blob_locked()

[Sergey Senozhatsky]

On (05/20/15 10:09), Jani Nikula wrote:
> > drm_property_unreference_blob_locked() is static and unused,
> > drop it.
> 
> http://mid.gmane.org/CAPj87rMPtafeYNzgXoP+fx0dAqhwaD7kdnJgqb_vdbPtiOrXPg at 
> mail.gmail.com
> 

oh, ok. thanks.

-ss

> >
> > Signed-off-by: Sergey Senozhatsky 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 19 ---
> >  1 file changed, 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 4059f06..6e60f71 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -4313,25 +4313,6 @@ void drm_property_unreference_blob(struct 
> > drm_property_blob *blob)
> >  EXPORT_SYMBOL(drm_property_unreference_blob);
> >  
> >  /**
> > - * drm_property_unreference_blob_locked - Unreference a blob property with 
> > blob_lock held
> > - *
> > - * Drop a reference on a blob property. May free the object. This must be
> > - * called with blob_lock held.
> > - *
> > - * @param dev  Device the blob was created on
> > - * @param blob Pointer to blob property
> > - */
> > -static void drm_property_unreference_blob_locked(struct drm_property_blob 
> > *blob)
> > -{
> > -   if (!blob)
> > -   return;
> > -
> > -   DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id, 
> > atomic_read(>refcount.refcount));
> > -
> > -   kref_put(>refcount, drm_property_free_blob);
> > -}
> > -
> > -/**
> >   * drm_property_reference_blob - Take a reference on an existing property
> >   *
> >   * Take a new reference on an existing blob property.
> > -- 
> > 2.4.1.168.g1ea28e1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> 

[Intel-gfx] [PATCH 6/8] pwm: crc: Add Crystalcove (CRC) PWM driver

[Shobhit Kumar]

On Thu, May 7, 2015 at 12:49 PM, Shobhit Kumar  wrote:
> On Wed, May 6, 2015 at 5:44 PM, Thierry Reding  
> wrote:
>> On Tue, May 05, 2015 at 03:08:36PM +0530, Shobhit Kumar wrote:
>>> The Crystalcove PMIC controls PWM signals and this driver exports that
>>
>> You say signal_s_ here, but you only expose a single PWM device. Does
>> the PMIC really control more than one? If it isn't, this should probably
>> become: "controls a PWM output and this driver...".
>
> Actually it does support 3 of them but on the platform only one is
> being used and I exported only that as of now. Probably I should
> expand a little in the commit message indicating this. will re-post
> after fixing based on your other comments.

Updates pending due to personal leave. Can be expected next week.

Regards
Shobhit

>
> Regards
> Shobhit
>
>>
>>> capability as a PWM chip driver. This is platform device implementtaion
>>
>> "implementation"
>>
>>> of the drivers/mfd cell device for CRC PMIC
>>
>> Sentences should end with a full stop.
>>
>>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>>> index b1541f4..954da3e 100644
>>> --- a/drivers/pwm/Kconfig
>>> +++ b/drivers/pwm/Kconfig
>>> @@ -183,6 +183,13 @@ config PWM_LPC32XX
>>> To compile this driver as a module, choose M here: the module
>>> will be called pwm-lpc32xx.
>>>
>>> +config PWM_CRC
>>> + bool "Intel Crystalcove (CRC) PWM support"
>>> + depends on X86 && INTEL_SOC_PMIC
>>> + help
>>> +   Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
>>> +   control.
>>> +
>>
>> This is badly sorted. Please keep the list sorted alphabetically.
>>
>>>  config PWM_LPSS
>>>   tristate "Intel LPSS PWM support"
>>>   depends on X86
>>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>>> index ec50eb5..3d38fed 100644
>>> --- a/drivers/pwm/Makefile
>>> +++ b/drivers/pwm/Makefile
>>> @@ -35,3 +35,4 @@ obj-$(CONFIG_PWM_TIPWMSS)   += pwm-tipwmss.o
>>>  obj-$(CONFIG_PWM_TWL)+= pwm-twl.o
>>>  obj-$(CONFIG_PWM_TWL_LED)+= pwm-twl-led.o
>>>  obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
>>> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
>>
>> This too.
>>
>>> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
>>> new file mode 100644
>>> index 000..987f3b4
>>> --- /dev/null
>>> +++ b/drivers/pwm/pwm-crc.c
>>> @@ -0,0 +1,171 @@
>>> +/*
>>> + * pwm-crc.c - Intel Crystal Cove PWM Driver
>>
>> I think you can safely remove this line. You already know what file it
>> is when you open it in your editor, and the description is in the
>> MODULE_DESCRIPTION string already.
>>
>>> + *
>>> + * Copyright (C) 2015 Intel Corporation. All rights reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License version
>>> + * 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Author: Shobhit Kumar 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define PWM0_CLK_DIV 0x4B
>>> +#define  PWM_OUTPUT_ENABLE   (1<<7)
>>
>> Should have spaces around <<.
>>
>>> +#define  PWM_DIV_CLK_0   0x00 /* DIVIDECLK = BASECLK */
>>> +#define  PWM_DIV_CLK_100 0x63 /* DIVIDECLK = BASECLK/100 */
>>> +#define  PWM_DIV_CLK_128 0x7F /* DIVIDECLK = BASECLK/128 */
>>> +
>>> +#define PWM0_DUTY_CYCLE  0x4E
>>> +#define BACKLIGHT_EN 0x51
>>> +
>>> +#define PWM_MAX_LEVEL0xFF
>>> +
>>> +#define PWM_BASE_CLK 6000/* 6 MHz */
>>
>> This number is actually 6 KHz. I think it'd be better if you stuck with
>> one unit here. Or perhaps there's some other reason why you can't use
>> 600 here instead?
>>
>>> +#define PWM_MAX_PERIOD_NS21333 /* 46.875KHz */
>>> +
>>> +/**
>>> + * struct crystalcove_pwm - Crystal Cove PWM controller
>>> + * @chip: the abstract pwm_chip structure.
>>> + * @regmap: the regmap from the parent device.
>>> + */
>>> +struct crystalcove_pwm {
>>> + struct pwm_chip chip;
>>> + struct platform_device *pdev;
>>
>> I think I had at some point requested that you get rid of this and use
>> the chip.dev member instead. There's no kerneldoc for it and it isn't
>> (well, almost, see below) used anywhere else, so perhaps you forgot to
>> remove it here?
>>
>>> + struct regmap *regmap;
>>> +};
>>> +
>>> +static inline struct crystalcove_pwm *to_crc_pwm(struct pwm_chip *pc)
>>> +{
>>> + return container_of(pc, struct crystalcove_pwm, chip);
>>> +}
>>> +
>>> +static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
>>> +{
>>> + struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
>>> +
>>> + 

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #88 from Oliver Winker  ---
(In reply to r.andersen from comment #84)
> ... and I should add
> 
> echo "50" > pwm1
> 
> also makes my computer hang.

Exactly the same on my HD7850 (see [1]) on kernel v4.0. 

Are there maybe hints how to debug this ?

[1]
---
Linux gamix64 4.0.0-owi1+ #1 SMP Sat May 9 10:17:17 CEST 2015 x86_64 GNU/Linux
---
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Pitcairn PRO [Radeon HD 7850] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 7850 2GB
GDDR5 DVI-I/DVI-D/HDMI/DP
Flags: bus master, fast devsel, latency 0, IRQ 36
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f500 (64-bit, non-prefetchable) [size=256K]
I/O ports at a000 [size=256]
[virtual] Expansion ROM at f400 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Capabilities: [150] Advanced Error Reporting
Capabilities: [270] #19
Capabilities: [2b0] Address Translation Service (ATS)
Capabilities: [2c0] #13
Capabilities: [2d0] #1b
Kernel driver in use: radeon
---

-- 
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/20150520/e644af9e/attachment.html>

[PATCH 1/2] drm/exynos: calculate vrefresh instead of use a fixed value

[Tobias Jakobi]

On 2015-05-20 16:33, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> When mode's vrefresh is zero we should ask DRM core to calculate 
> vrefresh
> for us so we can get the correct value instead of relying on fixed 
> value
> defined in a macro.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9819fa6..08f7197 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -42,7 +42,6 @@
>   * CPU Interface.
>   */
> 
> -#define FIMD_DEFAULT_FRAMERATE 60
>  #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
> 
>  /* position control register for hardware window 0, 2 ~ 4.*/
> @@ -329,7 +328,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc 
> *crtc,
>   struct drm_display_mode *adjusted_mode)
>  {
>   if (adjusted_mode->vrefresh == 0)
Well, I'm not completly sure how this all works, but shouldn't we check 
'mode' here, and not 'adjusted_mode'?

With best wishes,
Tobias


> - adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
> + adjusted_mode->vrefresh = drm_mode_vrefresh(mode);
> 
>   return true;
>  }

4.1-rc4 display-port on radeon not working

[Malte Schröder]

On 05/20/15 17:37, Alex Deucher wrote:
> On Tue, May 19, 2015 at 6:03 PM, Malte Schröder  wrote:
>> Hi,
>> with 4.1-rc display-port on my Tahiti XT stopped working. I used the
>> firmware from http://people.freedesktop.org/~agd5f/radeon_ucode/ as of
>> today.
>> Note: the display is an Asus PB278, it used to have problems with
>> display port negotiation, but those disappeared like a year ago.
>>
> 
> Does booting with radeon.auxch=0 on the kernel command line in grub
> help?  Can you bisect?
> 
> Alex
> 

Yes, radeon.auxch=0 helps. As for bisecting, I can try, but I won't have
time for that until next week.

-- 
Gruß
Malte Schröder
-
MalteSch at gmx.de

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

[PATCH 2/2] drm/exynos: WARN_ON if ideal_clk is zero

[Tobias Jakobi]

On 2015-05-20 18:14, Daniel Stone wrote:
> Hi,
> 
> On 20 May 2015 at 17:04, Tobias Jakobi  
> wrote:
>> Hmm,
>> 
>> I wonder if that really 'fixes' anything, because now we get a WARN_ON 
>> which
>> is immediately followed by a div-by-zero. Furthermore we then still 
>> use the
>> result of that operation as input for a hw register (bad idea?)
>> 
>> I thought of something like this. Change fimd_calc_clkdiv() to return 
>> a
>> signed value (this shouldn't be a problem, since the returned number 
>> range
>> is small anywary). Let fimd_calc_clkdiv() return -1 when it encounters 
>> the
>> 'ideal_clk == 0' case. Move computation of clkdiv in fimd_commit() to 
>> the
>> top of the function (right after the {h,v}total checks). If 'clkdiv == 
>> -1'
>> case is encountered, then do WARN_ON and return immediately from
>> fimd_commit().
>> 
>> Should I prepare a patch for this, or does someone see an issue with 
>> this
>> approach?
> 
> Commit should never fail; as I said earlier, the right fix is to
> reject these modes during checking, by making sure that any mode which
> passes mode_fixup() and/or mode_valid() never trips this condition.
But then in this case it wouldn't help to call drm_mode_vrefresh() 
during fixup, since it still returns zero, so we're in the same 
situation as before.

I even wonder if fixup is doing anything at all. See my previous log in:
http://www.spinics.net/lists/linux-samsung-soc/msg44683.html

This is with the old code in fixup that should set vrefresh to 60.

And we see that it's actually called:
[  135.978878] [drm:fimd_mode_fixup] vrefresh 0

But then a small while later:
[  135.979048] [drm:fimd_calc_clkdiv] vrefresh 0

So apparantly nothing was fixed up here anyway?!

With best wishes,
Tobias




> 
> Cheers,
> Daniel

[PATCH 1/2] drm/exynos: calculate vrefresh instead of use a fixed value

[Daniel Stone]

Hi,

On 20 May 2015 at 17:58, Tobias Jakobi  wrote:
> On 2015-05-20 16:33, Gustavo Padovan wrote:
>> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
>> for us so we can get the correct value instead of relying on fixed value
>> defined in a macro.
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9819fa6..08f7197 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -42,7 +42,6 @@
>>   * CPU Interface.
>>   */
>>
>> -#define FIMD_DEFAULT_FRAMERATE 60
>>  #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>>
>>  /* position control register for hardware window 0, 2 ~ 4.*/
>> @@ -329,7 +328,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc
>> *crtc,
>> struct drm_display_mode *adjusted_mode)
>>  {
>> if (adjusted_mode->vrefresh == 0)
>
> Well, I'm not completly sure how this all works, but shouldn't we check
> 'mode' here, and not 'adjusted_mode'?

adjusted_mode is fine; it is pre-populated with the value from mode.
'mode' itself _must not_ be modified.

Mind you, this is missing a hunk to reject entirely invalid modes, i.e.:
if (adjusted_mode->vrefresh == 0)
adjusted_mode->vrefresh = drm_mode_vrefresh(adjusted_mode);
if (adjusted_mode->vrefresh == 0)
return false;

Cheers,
Daniel

[PATCH 2/2] drm/exynos: WARN_ON if ideal_clk is zero

[Daniel Stone]

Hi,

On 20 May 2015 at 17:31, Tobias Jakobi  wrote:
> On 2015-05-20 18:14, Daniel Stone wrote:
>> On 20 May 2015 at 17:04, Tobias Jakobi 
>> wrote:
>>> I wonder if that really 'fixes' anything, because now we get a WARN_ON
>>> which
>>> is immediately followed by a div-by-zero. Furthermore we then still use
>>> the
>>> result of that operation as input for a hw register (bad idea?)
>>>
>>> I thought of something like this. Change fimd_calc_clkdiv() to return a
>>> signed value (this shouldn't be a problem, since the returned number
>>> range
>>> is small anywary). Let fimd_calc_clkdiv() return -1 when it encounters
>>> the
>>> 'ideal_clk == 0' case. Move computation of clkdiv in fimd_commit() to the
>>> top of the function (right after the {h,v}total checks). If 'clkdiv ==
>>> -1'
>>> case is encountered, then do WARN_ON and return immediately from
>>> fimd_commit().
>>>
>>> Should I prepare a patch for this, or does someone see an issue with this
>>> approach?
>>
>>
>> Commit should never fail; as I said earlier, the right fix is to
>> reject these modes during checking, by making sure that any mode which
>> passes mode_fixup() and/or mode_valid() never trips this condition.
>
> But then in this case it wouldn't help to call drm_mode_vrefresh() during
> fixup, since it still returns zero, so we're in the same situation as
> before.

fixup can reject a mode entirely by returning false, which is the sane
thing to do here if the clock is zero.

> I even wonder if fixup is doing anything at all. See my previous log in:
> http://www.spinics.net/lists/linux-samsung-soc/msg44683.html
>
> This is with the old code in fixup that should set vrefresh to 60.
>
> And we see that it's actually called:
> [  135.978878] [drm:fimd_mode_fixup] vrefresh 0
>
> But then a small while later:
> [  135.979048] [drm:fimd_calc_clkdiv] vrefresh 0
>
> So apparantly nothing was fixed up here anyway?!

Ah. That would be because fimd_calc_clkdiv uses >base.mode
(passed by fimd_commit), instead of crtc->state->adjusted_mode. Does
making that change help?

Cheers,
Daniel

[PATCH 2/2] drm/exynos: WARN_ON if ideal_clk is zero

[Tobias Jakobi]

Hmm,

I wonder if that really 'fixes' anything, because now we get a WARN_ON 
which is immediately followed by a div-by-zero. Furthermore we then 
still use the result of that operation as input for a hw register (bad 
idea?)

I thought of something like this. Change fimd_calc_clkdiv() to return a 
signed value (this shouldn't be a problem, since the returned number 
range is small anywary). Let fimd_calc_clkdiv() return -1 when it 
encounters the 'ideal_clk == 0' case. Move computation of clkdiv in 
fimd_commit() to the top of the function (right after the {h,v}total 
checks). If 'clkdiv == -1' case is encountered, then do WARN_ON and 
return immediately from fimd_commit().

Should I prepare a patch for this, or does someone see an issue with 
this approach?

With best wishes,
Tobias


On 2015-05-20 16:33, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> ideal_clk is the divisor in an operation to find the clock divider so
> it can't never be zero or we will end up with a division by zero error.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 08f7197..294f9cf 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -309,6 +309,8 @@ static u32 fimd_calc_clkdiv(struct fimd_context 
> *ctx,
>   unsigned long ideal_clk = mode->htotal * mode->vtotal * 
> mode->vrefresh;
>   u32 clkdiv;
> 
> + WARN_ON(ideal_clk == 0);
> +
>   if (ctx->i80_if) {
>   /*
>* The frame done interrupt should be occurred prior to the

4.1-rc4 display-port on radeon not working

[Alex Deucher]

On Wed, May 20, 2015 at 12:57 PM, Malte Schröder  wrote:
> On 05/20/15 17:37, Alex Deucher wrote:
>> On Tue, May 19, 2015 at 6:03 PM, Malte Schröder  wrote:
>>> Hi,
>>> with 4.1-rc display-port on my Tahiti XT stopped working. I used the
>>> firmware from http://people.freedesktop.org/~agd5f/radeon_ucode/ as of
>>> today.
>>> Note: the display is an Asus PB278, it used to have problems with
>>> display port negotiation, but those disappeared like a year ago.
>>>
>>
>> Does booting with radeon.auxch=0 on the kernel command line in grub
>> help?  Can you bisect?
>>
>> Alex
>>
>
> Yes, radeon.auxch=0 helps. As for bisecting, I can try, but I won't have
> time for that until next week.

No need to bisect.  if auxch=0 helps, I know what commit broke it.
Does the attached patch help?

Alex


>
> --
> Gruß
> Malte Schröder
> -
> MalteSch at gmx.de
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-error-flag-checking-in-native-aux-pat.patch
Type: text/x-patch
Size: 1055 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/77b466de/attachment.bin>

Radeon Verde displayport failure.

[Alex Deucher]

On Thu, May 14, 2015 at 11:52 PM, Dave Jones  wrote:
> On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
>  > On Tue, May 12, 2015 at 8:04 PM, Dave Jones  
> wrote:
>  > > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
>  > >
>  > >  > > I tried tweaking the delays in 
> drm_dp_link_train_clock_recovery_delay, without any noticable
>  > >  > > difference.  Is there something else I can try to make it try 
> harder before giving up?
>  > >  > >
>  > >  >
>  > >  > Can you attach your boot dmesg output with drm.debug=0xf set?
>  > >  >
>  > >  > You might also check the dpcd values in the driver during boot up and
>  > >  > link training.  There appears to be an issue where that data gets
>  > >  > corrupted in some cases:
>  > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
>  > >
>  > > I tried both the 'disable spread spectrum' and 'grab dpcd info from 
> vbios for eDP'
>  > > patches from that bug. Again, no obvious difference.
>  > >
>  > > Log from kernel with both applied attached.
>  > >
>  > > Also a log file from after I woke up the LCD when it was in sleep mode.
>  > >
>  > > Something else curious is how it only discovers a maximum mode from the 
> LCD
>  > > of 1024x768.
>  >
>  > I looks like the monitor is not responding.  I'm not entirely sure
>  > what's going on.  I posted a new debugging patch on the bug report
>  > that will dump the dpcd at various times to see if and when it's
>  > getting corrupt.  Fixing that should at least get the monitor to come
>  > up reliably (assuming you are experiencing the same issue).
>
> Thanks to some back-and-forth on irc, airlied got this mostly working.
> The working combo seems to be..
>
> - Switch monitor to DP 1.2
> - boot with radeon.mst=1
> - apply the patch below
>
> With all that, it boots up, and X starts up in 2560x1440 like it should.
>
> The only remaining problem is there are some visible glitches, mostly 
> noticable
> while scrolling a terminal.
>
> Happy to continue applying further debug patches if you have any more ideas.
>

I think the attached patch should get aux working as reliably as the
old atom code.  The atom code ignores bits 12-14 when checking the
transaction flags.

Alex


> thanks,
> Dave
>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c 
> b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> index bf1fecc6cceb..3b401cc8d209 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> @@ -30,7 +30,6 @@
> AUX_SW_RX_HPD_DISCON |   \
> AUX_SW_RX_PARTIAL_BYTE | \
> AUX_SW_NON_AUX_MODE |\
> -   AUX_SW_RX_MIN_COUNT_VIOL |   \
> AUX_SW_RX_INVALID_STOP | \
>     AUX_SW_RX_SYNC_INVALID_L |   \
> AUX_SW_RX_SYNC_INVALID_H |   \
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-error-flag-checking-in-native-aux-pat.patch
Type: text/x-patch
Size: 1055 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/36501357/attachment.bin>

[PATCH v3] drm/exynos: calculate vrefresh instead of use a fixed value

[Gustavo Padovan]

From: Gustavo Padovan 

When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.

Suggested-by: Daniel Stone 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9819fa6..3f9646d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -42,7 +42,6 @@
  * CPU Interface.
  */

-#define FIMD_DEFAULT_FRAMERATE 60
 #define MIN_FB_WIDTH_FOR_16WORD_BURST 128

 /* position control register for hardware window 0, 2 ~ 4.*/
@@ -329,7 +328,9 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
 {
if (adjusted_mode->vrefresh == 0)
-   adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
+   adjusted_mode->vrefresh = drm_mode_vrefresh(mode);
+   if (adjusted_mode->vrefresh == 0)
+   return false;

return true;
 }
@@ -427,7 +428,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
if (ctx->driver_data->has_clksel)
val |= VIDCON0_CLKSEL_LCD;

-   clkdiv = fimd_calc_clkdiv(ctx, mode);
+   clkdiv = fimd_calc_clkdiv(ctx, >base.state->adjusted_mode);
if (clkdiv > 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;

-- 
2.1.0

[PATCH v2] drm/exynos: calculate vrefresh instead of use a fixed value

[Gustavo Padovan]

2015-05-20 Tobias Jakobi :

> Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> > for us so we can get the correct value instead of relying on fixed value
> > defined in a macro. But if vrefresh is still zero we should fail the
> > update.
> Even with this we still need to consider crtc->state->adjusted_mode in
> fimd_commit(), otherwise vrefresh computed by drm_mode_vrefresh() is
> never actually used.

You are right, I think we should pass crtc->state->adjusted_mode to
fimd_calc_clkdiv(). I'll send a v3 with this change.

Gustavo

[Nouveau] [PATCH] ram/gf100-: error out if a ridiculous amount of vram is detected

[Ilia Mirkin]

Someone will have to trudge through a mmiotrace and figure out what
magic bit we need to set in order to bring it out of deep sleep. Or
perhaps NVIDIA will graciously tell us, which they eventually did for
GK104/GK106 (but their instructions appear to be insufficient for at
least some GK106's).

But I've seen these errors every so often on various cards... we stick
things at the end of VRAM, which causes no end of confusion when we
think that it's a few PB out :)

On Wed, May 20, 2015 at 5:35 PM, Tobias Klausmann
 wrote:
> Any idea on how to solve the problem. other than just reporting it?
>
> But for now this adds a helpful error message... you may add my R-b.
>
>
> On 20.05.2015 22:01, Ilia Mirkin wrote:
>>
>> Some newer chips have trouble coming up, and we get bad MMIO reads from
>> them, like 0xbadf100. This ends up translating into crazy amounts of
>> VRAM, which destroys all sorts of other logic down the line. Instead,
>> fail device init.
>>
>> Signed-off-by: Ilia Mirkin 
>> Cc: stable at kernel.org
>> ---
>>   drm/nouveau/nvkm/subdev/fb/ramgf100.c | 6 ++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c
>> b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
>> index de9f395..9d4d196 100644
>> --- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c
>> +++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
>> @@ -545,6 +545,12 @@ gf100_ram_create_(struct nvkm_object *parent, struct
>> nvkm_object *engine,
>> }
>> }
>>   + /* if over 1TB of VRAM is reported, something went very wrong,
>> bail */
>> +   if (ram->size > (1ULL << 40)) {
>> +   nv_error(pfb, "invalid vram size: %llx\n", ram->size);
>> +   return -EINVAL;
>> +   }
>> +
>> /* if all controllers have the same amount attached, there's no
>> holes */
>> if (uniform) {
>> offset = rsvd_head;
>
>

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

[Daniel Vetter]

On Wed, May 20, 2015 at 11:15:27AM -0400, Rob Clark wrote:
> Using fb modifier flag, support NV12MT format in MDP4.
> 
> v2:
> - rework the modifier's description [Daniel Vetter's comment]
> - drop .set_mode_config() callback [Rob Clark's comment]
> v3:
> - change VENDOR's name and restrict usage to NV12 [pointed by Daniel]
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_crtc.c| 14 ++
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
>  include/uapi/drm/drm_fourcc.h | 15 +++
>  4 files changed, 53 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3007b44..ed5d3f9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3304,6 +3304,20 @@ static int framebuffer_check(const struct 
> drm_mode_fb_cmd2 *r)
> r->modifier[i], i);
>   return -EINVAL;
>   }
> +
> + /* modifier specific checks: */
> + switch (r->modifier[i]) {
> + case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
> + if (r->pixel_format != DRM_FORMAT_NV12 ||
> + width % 128 || height % 32) {
> + DRM_DEBUG_KMS("bad modifier data for plane 
> %d\n", i);
> + return -EINVAL;
> + }

Should we also check that the stride matches the macroblock size? lgtm
otherwise.
-Daniel

> + break;
> +
> + default:
> + break;
> + }
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index d847b94..88a75cb 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -119,6 +119,8 @@ static int mdp4_hw_init(struct msm_kms *kms)
>   if (mdp4_kms->rev > 1)
>   mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
>  
> + dev->mode_config.allow_fb_modifiers = true;
> +
>  out:
>   pm_runtime_put_sync(dev->dev);
>  
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> index dbc0689..0d1dbb7 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> @@ -33,6 +33,21 @@ struct mdp4_plane {
>  };
>  #define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)
>  
> +/* MDP format helper functions */
> +static inline
> +enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
> +{
> + bool is_tile = false;
> +
> + if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
> + is_tile = true;
> +
> + if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
> + return FRAME_TILE_YCBCR_420;
> +
> + return FRAME_LINEAR;
> +}
> +
>  static void mdp4_plane_set_scanout(struct drm_plane *plane,
>   struct drm_framebuffer *fb);
>  static int mdp4_plane_mode_set(struct drm_plane *plane,
> @@ -205,6 +220,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
>   uint32_t op_mode = 0;
>   uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
>   uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
> + enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);
>  
>   if (!(crtc && fb)) {
>   DBG("%s: disabled!", mdp4_plane->name);
> @@ -304,6 +320,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
>   MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count 
> - 1) |
>   MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type) |
>   MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample) 
> |
> + MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
>   COND(format->unpack_tight, 
> MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));
>  
>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
> @@ -324,6 +341,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);
>  
> + if (frame_type != FRAME_LINEAR)
> + mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
> + MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
> + MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
> +
>   return 0;
>  }
>  
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0773582..2f295cd 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -207,4 +207,19 @@
>   */
>  #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
>  
> +/*
> + * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized 

[PATCH] drm/edid: Fix DDC probe for passive DP dongles

[Todd Previte]

Passive DP->DVI/HDMI dongles show up to the system as HDMI devices, as they
do not have a sink device in them to respond to any AUX traffic. When
probing these dongles over the DDC, sometimes they will NAK the first attempt
even though the transaction is valid and they support the DDC protocol. The
retry loop inside of drm_do_probe_ddc_edid() would normally catch this case
and try the transaction again, resulting in success.

That, however, was thwarted by the fix for fdo.org bug #41059. The patch is:
commit 9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov 
Date:   Thu Jan 5 09:34:28 2012 -0200

drm: give up on edid retries when i2c bus is not responding

This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time spent
in waiting for unresponsive or disconnected devices. For the DP dongles,
this means that the second retry never happens which results in a failed
EDID probe and a black screen.

To work around this problem without undoing the fix for bug #41059, the
number of retries is checked along with the return code. This allows for a
device to NAK once and still continue operations. A second NAK will result
in breaking the loop as it would have before and stopping the DDC probe.

Signed-off-by: Todd Previte 
Cc: intel-gfx at lists.freedesktop.org
---
 drivers/gpu/drm/drm_edid.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7087da3..e8047bd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1238,7 +1238,10 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int 
block, size_t len)
 */
ret = i2c_transfer(adapter, [3 - xfers], xfers);

-   if (ret == -ENXIO) {
+   /* Passive DP->DVI/HDMI dongles sometimes NAK the first probe
+* Try to probe again but if it NAKs, stop trying
+*/
+   if (ret == -ENXIO && retries < 5) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
-- 
1.9.1

[PATCH 2/2] drm/exynos: WARN_ON if ideal_clk is zero

[Daniel Stone]

Hi,

On 20 May 2015 at 17:04, Tobias Jakobi  wrote:
> Hmm,
>
> I wonder if that really 'fixes' anything, because now we get a WARN_ON which
> is immediately followed by a div-by-zero. Furthermore we then still use the
> result of that operation as input for a hw register (bad idea?)
>
> I thought of something like this. Change fimd_calc_clkdiv() to return a
> signed value (this shouldn't be a problem, since the returned number range
> is small anywary). Let fimd_calc_clkdiv() return -1 when it encounters the
> 'ideal_clk == 0' case. Move computation of clkdiv in fimd_commit() to the
> top of the function (right after the {h,v}total checks). If 'clkdiv == -1'
> case is encountered, then do WARN_ON and return immediately from
> fimd_commit().
>
> Should I prepare a patch for this, or does someone see an issue with this
> approach?

Commit should never fail; as I said earlier, the right fix is to
reject these modes during checking, by making sure that any mode which
passes mode_fixup() and/or mode_valid() never trips this condition.

Cheers,
Daniel

[PATCH 6/7] drm: add RGB formats with separate alpha plane

[Daniel Vetter]

On Wed, May 20, 2015 at 04:54:01PM +0200, Philipp Zabel wrote:
> Am Mittwoch, den 20.05.2015, 17:07 +0300 schrieb Ville Syrjälä:
> > On Wed, May 20, 2015 at 02:58:53PM +0200, Daniel Vetter wrote:
> > > On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> > > > Hi Daniel,
> > > > 
> > > > thank you for the comments.
> > > > 
> > > > Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
> > > > [...]
> > > > > > @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > > > > unsigned int *depth,
> > > > > > break;
> > > > > > case DRM_FORMAT_RGB565:
> > > > > > case DRM_FORMAT_BGR565:
> > > > > > +   case DRM_FORMAT_RGB565_A8:
> > > > > > +   case DRM_FORMAT_BGR565_A8:
> > > > > > *depth = 16;
> > > > > > *bpp = 16;
> > > > > > break;
> > > > > > case DRM_FORMAT_RGB888:
> > > > > > case DRM_FORMAT_BGR888:
> > > > > > +   case DRM_FORMAT_RGB888_A8:
> > > > > > +   case DRM_FORMAT_BGR888_A8:
> > > > > > *depth = 24;
> > > > > > *bpp = 24;
> > > > > > break;
> > > > > > @@ -5210,6 +5222,10 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > > > > unsigned int *depth,
> > > > > > case DRM_FORMAT_XBGR:
> > > > > > case DRM_FORMAT_RGBX:
> > > > > > case DRM_FORMAT_BGRX:
> > > > > > +   case DRM_FORMAT_XRGB_A8:
> > > > > > +   case DRM_FORMAT_XBGR_A8:
> > > > > > +   case DRM_FORMAT_RGBX_A8:
> > > > > > +   case DRM_FORMAT_BGRX_A8:
> > > > > > *depth = 24;
> > > > > > *bpp = 32;
> > > > > > break;
> > > > > 
> > > > > Please drop the above two hunks, these functions are only for 
> > > > > backwards
> > > > > compat with drivers from the addfb1 days. Modern drivers should only 
> > > > > use
> > > > > the format tags directly. Extending the plane_cpp function like you do
> > > > > below is enough.
> > > > 
> > > > I'll leave drm_fb_get_bpp_depth untouched.
> > > > 
> > > > > Maybe we should add a WARN_ON(num_planes(format) != 0) to the top of 
> > > > > this
> > > > > and a comment that this is for legacy stuff only.
> > > > 
> > > > Do you mean:
> > > > 
> > > > -8<-
> > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -5186,6 +5186,12 @@ int drm_mode_destroy_dumb_ioctl(struct 
> > > > drm_device *dev,
> > > >  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
> > > >   int *bpp)
> > > >  {
> > > > +   /*
> > > > +* This function is to be used for legacy drivers only, no new 
> > > > formats
> > > > +* should be added here.
> > > > +*/
> > > > +   WARN_ON(drm_format_num_planes(format) != 1);
> > > > +
> > > > switch (format) {
> > > > case DRM_FORMAT_C8:
> > > > case DRM_FORMAT_RGB332:
> > > > ->8-
> > > 
> > > Yeah that looks perfect, please wrap with commit message and I'll
> > > apply.
> > 
> > I think that's going to trigger a lot. IIRC we call this thing for
> > any format when constructing FBs.
> 
> Yes I just noticed that too, for example via:
> 
> drm_fb_cma_create -> drm_fb_cma_alloc -> drm_helper_mode_fill_fb_struct
> -> drm_fb_get_bpp_depth

Hm right, so perhaps just a comment then?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 6/7] drm: add RGB formats with separate alpha plane

[Ville Syrjälä]

On Wed, May 20, 2015 at 02:58:53PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> > Hi Daniel,
> > 
> > thank you for the comments.
> > 
> > Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
> > [...]
> > > > @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > > unsigned int *depth,
> > > > break;
> > > > case DRM_FORMAT_RGB565:
> > > > case DRM_FORMAT_BGR565:
> > > > +   case DRM_FORMAT_RGB565_A8:
> > > > +   case DRM_FORMAT_BGR565_A8:
> > > > *depth = 16;
> > > > *bpp = 16;
> > > > break;
> > > > case DRM_FORMAT_RGB888:
> > > > case DRM_FORMAT_BGR888:
> > > > +   case DRM_FORMAT_RGB888_A8:
> > > > +   case DRM_FORMAT_BGR888_A8:
> > > > *depth = 24;
> > > > *bpp = 24;
> > > > break;
> > > > @@ -5210,6 +5222,10 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > > unsigned int *depth,
> > > > case DRM_FORMAT_XBGR:
> > > > case DRM_FORMAT_RGBX:
> > > > case DRM_FORMAT_BGRX:
> > > > +   case DRM_FORMAT_XRGB_A8:
> > > > +   case DRM_FORMAT_XBGR_A8:
> > > > +   case DRM_FORMAT_RGBX_A8:
> > > > +   case DRM_FORMAT_BGRX_A8:
> > > > *depth = 24;
> > > > *bpp = 32;
> > > > break;
> > > 
> > > Please drop the above two hunks, these functions are only for backwards
> > > compat with drivers from the addfb1 days. Modern drivers should only use
> > > the format tags directly. Extending the plane_cpp function like you do
> > > below is enough.
> > 
> > I'll leave drm_fb_get_bpp_depth untouched.
> > 
> > > Maybe we should add a WARN_ON(num_planes(format) != 0) to the top of this
> > > and a comment that this is for legacy stuff only.
> > 
> > Do you mean:
> > 
> > -8<-
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -5186,6 +5186,12 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device 
> > *dev,
> >  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
> >   int *bpp)
> >  {
> > +   /*
> > +* This function is to be used for legacy drivers only, no new formats
> > +* should be added here.
> > +*/
> > +   WARN_ON(drm_format_num_planes(format) != 1);
> > +
> > switch (format) {
> > case DRM_FORMAT_C8:
> > case DRM_FORMAT_RGB332:
> > ->8-
> 
> Yeah that looks perfect, please wrap with commit message and I'll
> apply.

I think that's going to trigger a lot. IIRC we call this thing for
any format when constructing FBs.

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH] Documentation/drm: Update rotation property with 90/270 and description

[Ville Syrjälä]

On Wed, May 20, 2015 at 01:19:34PM +0530, Jindal, Sonika wrote:
> 
> 
> On 5/13/2015 9:57 AM, Jindal, Sonika wrote:
> >
> >
> > On 5/12/2015 6:20 PM, Ville Syrjälä wrote:
> >> On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:
> >>> Cc: dri-devel at lists.freedesktop.org
> >>> Signed-off-by: Sonika Jindal 
> >>> ---
> >>>   Documentation/DocBook/drm.tmpl |7 +--
> >>>   1 file changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/Documentation/DocBook/drm.tmpl
> >>> b/Documentation/DocBook/drm.tmpl
> >>> index f4976cd..266d50a 100644
> >>> --- a/Documentation/DocBook/drm.tmpl
> >>> +++ b/Documentation/DocBook/drm.tmpl
> >>> @@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
> >>>   Plane
> >>>   “rotation”
> >>>   BITMASK
> >>> -{ 0, "rotate-0" }, { 2, "rotate-180" }
> >>> +{ 0, "rotate-0" }, { 1, "rotate-90" },
> >>> +{ 2, "rotate-180" }, { 3, "rotate-270" }
> >>>   Plane
> >>> -TBD
> >>> +To set plane HW rotation. This rotation
> >>> property does
> >>> +the plane rotation in counter clockwise direction which is
> >>> +inline with the way XRandr works.
> >>
> >> I would suggest moving the thing to the generci props section since we
> >> have omap and i915 both supporting it.
> > You mean in DRM properties section?
> > Right now, OMAP section also has rotation property. I will remove it
> > from OMAP section as well if you think drm is the better place.
> >
> >>
> >> As for the description, we should also document the reflect flags.
> >>
> i915 doesn't support reflect flags.

It will as soon as I (or someone else) find a bit of time to implement
it.

> It only create rotation property 
> with rotation flags.
> 
> For "generic" section, you mean moving to generic group of properties in 
> i915 only right?

I meant the entire thing. I don't think we should care too much about
which actual bits each driver supports since that can even depend on
which plane is used in some specific platform. So we should just
document all the possible bits, and if you want you could add a note
stating that a specific driver/platform/plane may not support all of
them.

> >> I might write it as something like this:
> >> "rotate-0,rotate-90,rotate-180,rotate-270 rotate the image by the
> >> specified amount in degrees in a counter clockwise direction.
> >> reflect-x,reflect-y reflect the image along the specified axis,
> >> prior to rotation."
> >>
> >>>   
> >>>   
> >>>   SDVO-TV
> >>> --
> >>> 1.7.10.4
> >>>
> >>> ___
> >>> Intel-gfx mailing list
> >>> Intel-gfx at lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >>

-- 
Ville Syrjälä
Intel OTC

[PATCH 6/7] drm: add RGB formats with separate alpha plane

[Philipp Zabel]

Am Mittwoch, den 20.05.2015, 17:07 +0300 schrieb Ville Syrjälä:
> On Wed, May 20, 2015 at 02:58:53PM +0200, Daniel Vetter wrote:
> > On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> > > Hi Daniel,
> > > 
> > > thank you for the comments.
> > > 
> > > Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
> > > [...]
> > > > > @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > > > unsigned int *depth,
> > > > >   break;
> > > > >   case DRM_FORMAT_RGB565:
> > > > >   case DRM_FORMAT_BGR565:
> > > > > + case DRM_FORMAT_RGB565_A8:
> > > > > + case DRM_FORMAT_BGR565_A8:
> > > > >   *depth = 16;
> > > > >   *bpp = 16;
> > > > >   break;
> > > > >   case DRM_FORMAT_RGB888:
> > > > >   case DRM_FORMAT_BGR888:
> > > > > + case DRM_FORMAT_RGB888_A8:
> > > > > + case DRM_FORMAT_BGR888_A8:
> > > > >   *depth = 24;
> > > > >   *bpp = 24;
> > > > >   break;
> > > > > @@ -5210,6 +5222,10 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > > > unsigned int *depth,
> > > > >   case DRM_FORMAT_XBGR:
> > > > >   case DRM_FORMAT_RGBX:
> > > > >   case DRM_FORMAT_BGRX:
> > > > > + case DRM_FORMAT_XRGB_A8:
> > > > > + case DRM_FORMAT_XBGR_A8:
> > > > > + case DRM_FORMAT_RGBX_A8:
> > > > > + case DRM_FORMAT_BGRX_A8:
> > > > >   *depth = 24;
> > > > >   *bpp = 32;
> > > > >   break;
> > > > 
> > > > Please drop the above two hunks, these functions are only for backwards
> > > > compat with drivers from the addfb1 days. Modern drivers should only use
> > > > the format tags directly. Extending the plane_cpp function like you do
> > > > below is enough.
> > > 
> > > I'll leave drm_fb_get_bpp_depth untouched.
> > > 
> > > > Maybe we should add a WARN_ON(num_planes(format) != 0) to the top of 
> > > > this
> > > > and a comment that this is for legacy stuff only.
> > > 
> > > Do you mean:
> > > 
> > > -8<-
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -5186,6 +5186,12 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device 
> > > *dev,
> > >  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
> > > int *bpp)
> > >  {
> > > + /*
> > > +  * This function is to be used for legacy drivers only, no new formats
> > > +  * should be added here.
> > > +  */
> > > + WARN_ON(drm_format_num_planes(format) != 1);
> > > +
> > >   switch (format) {
> > >   case DRM_FORMAT_C8:
> > >   case DRM_FORMAT_RGB332:
> > > ->8-
> > 
> > Yeah that looks perfect, please wrap with commit message and I'll
> > apply.
> 
> I think that's going to trigger a lot. IIRC we call this thing for
> any format when constructing FBs.

Yes I just noticed that too, for example via:

drm_fb_cma_create -> drm_fb_cma_alloc -> drm_helper_mode_fill_fb_struct
-> drm_fb_get_bpp_depth

regards
Philipp

[PATCH] drm: check for garbage in unused addfb2 fields

[Daniel Vetter]

Unfortunately old userspace didn't clear this properly, but since
we've added fb modifiers that's fixed. Checking properly that unused
fields is important for abi extensions, and just right now there's a
bunch of discussions going on about how exactly the additional aux
planes for render compression should be specified.

So let's first make sure that the values in those additional fields
can be indeed used.

Cc: Thierry Reding 
Testcase: igt/kms_addfb/unused-*
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2e26988a9762..8ad582f4026b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3308,6 +3308,32 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
}
}

+   for (i = num_planes; i < 4; i++) {
+   if (r->modifier[i]) {
+   DRM_DEBUG_KMS("non-zero modifier for unused plane 
%d\n", i);
+   return -EINVAL;
+   }
+
+   /* Pre-FB_MODIFIERS userspace didn't clear the structs 
properly. */
+   if (!(r->flags & DRM_MODE_FB_MODIFIERS))
+   continue;
+
+   if (r->handles[i]) {
+   DRM_DEBUG_KMS("buffer object handle for unused plane 
%d\n", i);
+   return -EINVAL;
+   }
+
+   if (r->pitches[i]) {
+   DRM_DEBUG_KMS("non-zero pitch for unused plane %d\n", 
i);
+   return -EINVAL;
+   }
+
+   if (r->offsets[i]) {
+   DRM_DEBUG_KMS("non-zero offset for unused plane %d\n", 
i);
+   return -EINVAL;
+   }
+   }
+
return 0;
 }

-- 
2.1.4

DP MST oops

[Jani Nikula]

Dave -

My Haswell oopses when power cycling an MST enabled Dell P2415Q display.

I haven't been able to get a picture on screen when either the sink or
the source has MST enabled, but one thing at a time...

Below is the only snippet of dmesg I've been able to squeeze out at this
time, maybe it gives you some clues. I just crudely tail -f /proc/kmsg
to get something out so it's less than perfect.

I've been eyeballing drm_dp_add_port with suspicion. It looks like if
port == NULL (and thus created is true) *and* port_msg->port_number >=
8, drm_get_edid gets called with an uninitialized port->aux.ddc. My
quick attempts at changing the conditions for calling
drm_dp_port_teardown_pdt and drm_dp_port_setup_pdt were, however,
unsuccesful.

Any ideas?

In the mean time I'll try to scavenge another MST source so I don't have
to keep rebooting my main dev machine... ;)

BR,
Jani.



<7>[  987.227610] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
[CONNECTOR:48:HDMI-A-2] disconnected
<7>[  987.227613] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
[CONNECTOR:48:HDMI-A-2]
<7>[  987.227770] [drm:gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr: 0050 
r(1)
<7>[  987.227772] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
[CONNECTOR:48:HDMI-A-2] disconnected
<7>[  993.630496] [drm:intel_dp_print_rates] sink rates: 162000, 27, 54
<7>[  993.631248] [drm:intel_dp_probe_oui] Sink OUI: 00
<7>[  993.631852] [drm:intel_dp_probe_mst] Sink is MST capable
<7>[  993.656698] [drm:intel_hpd_irq_handler] hotplug event received, stat 
0x0020, dig 0x00101011
<7>[  993.656702] [drm:intel_hpd_irq_handler] digital hpd port B - short
<7>[  993.656719] [drm:intel_dp_hpd_pulse] got hpd irq on port B - short
<7>[  993.662942] [drm:intel_dp_check_mst_status] got esi 41 10 00
<7>[  993.664008] [drm:intel_dp_check_mst_status] got esi2 41 00 00
<7>[  993.664010] [drm:intel_dp_check_mst_status] got esi 41 00 00
<7>[  993.668159] [drm:intel_hpd_irq_handler] digital hpd port B - short
<7>[  993.668597] [drm:intel_dp_check_mst_status] got esi 41 10 00
<7>[  993.669095] [drm:drm_dp_send_link_address] port 0: input 1, pdt: 1, pn: 
0, dpcd_rev: 00, mcs: 1, ddps: 1, ldps 0, sdp 0/0
<7>[  993.669100] [drm:drm_dp_send_link_address] port 2: input 0, pdt: 0, pn: 
8, dpcd_rev: 00, mcs: 0, ddps: 0, ldps 0, sdp 0/0
<1>[  993.669333] IP: [] i2c_transfer+0x10/0xd0 [i2c_core]
<4>[  993.669378] Oops:  [#1] SMP 
 af_alg hid_generic usbhid hid dm_crypt dm_mod sg sd_mod rtsx_pci_sdmmc 
mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci 
libata scsi_mod xhci_pci ehci_pci e1000e rtsx_pci xhci_hcd ehci_hcd mfd_core 
ptp pps_core usbcore usb_common thermal thermal_sys
<4>[  993.670009] Hardware name: Notebook W740SU
  /W740SU  , BIOS 4.6.5 04/21/2014
<4>[  993.670100] task: 880409bb0be0 ti: 880409bb8000 task.ti: 
880409bb8000
<4>[  993.670173] RSP: 0018:88040918  EFLAGS: 00010246
<4>[  993.670226] RDX: 0002 RSI: 88040968 RDI: 
880409ec7840
<4>[  993.670287] R10: 0001 R11:  R12: 
0002
<4>[  993.670348] FS:  () GS:88041f60() 
knlGS:
<4>[  993.670406] CR2:  CR3: 0180d000 CR4: 
001407f0
<4>[  993.670446]  0005 0001 0002 
a046045c
<4>[  993.670518]  00010030 88040957 00010050 
88040956
<4>[  993.670574]  [] ? drm_do_probe_ddc_edid+0xcc/0x150 [drm]
<4>[  993.670647]  [] ? 
intel_dp_add_mst_connector+0x115/0x140 [i915]
<4>[  993.670716]  [] ? printk+0x4d/0x52
<4>[  993.670774]  [] ? drm_dp_send_link_address+0x17b/0x220 
[drm_kms_helper]
<4>[  993.670850]  [] ? process_one_work+0x14d/0x410
<4>[  993.670902]  [] ? __schedule+0x2a0/0x8f0
<4>[  993.670953]  [] ? kthread+0xd3/0xf0
<4>[  993.671004]  [] ? ret_from_fork+0x42/0x70
<4>[  993.671057] Code: ff ff 45 31 ed e9 c4 fe ff ff 45 31 e4 e9 55 fd ff ff 
66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 47 10 48 89 fb <48> 
83 38 00 0f 84 86 00 00 00 65 8b 05 9f 8d c4 5f a9 ff ff df 
<4>[  993.671241]  RSP 
<4>[  993.684371] ---[ end trace 34f0c3d1ac8f2574 ]---
<1>[  993.684455] BUG: unable to handle kernel paging request at 
ffd8
<1>[  993.684492] IP: [] kthread_data+0xc/0x20
<4>[  993.684525] PGD 1810067 PUD 1812067 PMD 0 
<4>[  993.684569] Modules linked in: uvcvideo videobuf2_vmalloc 
videobuf2_memops videobuf2_core v4l2_common videodev media binfmt_misc bnep 
nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc joydev 
nls_utf8 nls_cp437 vfat snd_hda_


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] ram/gf100-: error out if a ridiculous amount of vram is detected

[Ilia Mirkin]

Some newer chips have trouble coming up, and we get bad MMIO reads from
them, like 0xbadf100. This ends up translating into crazy amounts of
VRAM, which destroys all sorts of other logic down the line. Instead,
fail device init.

Signed-off-by: Ilia Mirkin 
Cc: stable at kernel.org
---
 drm/nouveau/nvkm/subdev/fb/ramgf100.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c 
b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
index de9f395..9d4d196 100644
--- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c
+++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
@@ -545,6 +545,12 @@ gf100_ram_create_(struct nvkm_object *parent, struct 
nvkm_object *engine,
}
}

+   /* if over 1TB of VRAM is reported, something went very wrong, bail */
+   if (ram->size > (1ULL << 40)) {
+   nv_error(pfb, "invalid vram size: %llx\n", ram->size);
+   return -EINVAL;
+   }
+
/* if all controllers have the same amount attached, there's no holes */
if (uniform) {
offset = rsvd_head;
-- 
2.3.6

[PATCH] drm/msm: dsi: fix compile errors when CONFIG_GPIOLIB=n

[Brian Norris]

I'm not sure where, exactly, but somewhere in here we must be relying on
an implicit include.

drivers/gpu/drm/msm/dsi/dsi_host.c: In function ‘dsi_host_init_panel_gpios’:
drivers/gpu/drm/msm/dsi/dsi_host.c:1356:2: error: implicit declaration of 
function ‘devm_gpiod_get’ [-Werror=implicit-function-declaration]
  msm_host->disp_en_gpio = devm_gpiod_get(panel_device,
  ^
drivers/gpu/drm/msm/dsi/dsi_host.c:1356:25: warning: assignment makes pointer 
from integer without a cast [enabled by default]
  msm_host->disp_en_gpio = devm_gpiod_get(panel_device,
 ^
drivers/gpu/drm/msm/dsi/dsi_host.c:1364:3: error: implicit declaration of 
function ‘gpiod_direction_output’ [-Werror=implicit-function-declaration]
   ret = gpiod_direction_output(msm_host->disp_en_gpio, 0);
   ^
drivers/gpu/drm/msm/dsi/dsi_host.c:1371:20: warning: assignment makes pointer 
from integer without a cast [enabled by default]
  msm_host->te_gpio = devm_gpiod_get(panel_device, "disp-te");
^
drivers/gpu/drm/msm/dsi/dsi_host.c:1378:3: error: implicit declaration of 
function ‘gpiod_direction_input’ [-Werror=implicit-function-declaration]
   ret = gpiod_direction_input(msm_host->te_gpio);
   ^
drivers/gpu/drm/msm/dsi/dsi_host.c: In function ‘msm_dsi_host_power_on’:
drivers/gpu/drm/msm/dsi/dsi_host.c:1918:3: error: implicit declaration of 
function ‘gpiod_set_value’ [-Werror=implicit-function-declaration]
   gpiod_set_value(msm_host->disp_en_gpio, 1);
   ^

Signed-off-by: Brian Norris 
Cc: David Airlie 
Cc: Rob Clark 
Cc: Hai Li 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 956b22492c9a..98aae759f2fd 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.9.1

[PATCH 1/2] drm/exynos: calculate vrefresh instead of use a fixed value

[Gustavo Padovan]

Hi,

2015-05-20 Daniel Stone :

> Hi,
> 
> On 20 May 2015 at 17:58, Tobias Jakobi  
> wrote:
> > On 2015-05-20 16:33, Gustavo Padovan wrote:
> >> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> >> for us so we can get the correct value instead of relying on fixed value
> >> defined in a macro.
> >>
> >> Signed-off-by: Gustavo Padovan 
> >> ---
> >>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 +--
> >>  1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> index 9819fa6..08f7197 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> @@ -42,7 +42,6 @@
> >>   * CPU Interface.
> >>   */
> >>
> >> -#define FIMD_DEFAULT_FRAMERATE 60
> >>  #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
> >>
> >>  /* position control register for hardware window 0, 2 ~ 4.*/
> >> @@ -329,7 +328,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc
> >> *crtc,
> >> struct drm_display_mode *adjusted_mode)
> >>  {
> >> if (adjusted_mode->vrefresh == 0)
> >
> > Well, I'm not completly sure how this all works, but shouldn't we check
> > 'mode' here, and not 'adjusted_mode'?
> 
> adjusted_mode is fine; it is pre-populated with the value from mode.
> 'mode' itself _must not_ be modified.
> 
> Mind you, this is missing a hunk to reject entirely invalid modes, i.e.:
> if (adjusted_mode->vrefresh == 0)
> adjusted_mode->vrefresh = drm_mode_vrefresh(adjusted_mode);
> if (adjusted_mode->vrefresh == 0)
> return false;

I have sent a v2 with the proposed change. I can't really test this here
as I don't have the hardware where it fails. So in v1 I was just
guessing that it would fix the issue.

Gustavo

[PATCH v2] drm/exynos: calculate vrefresh instead of use a fixed value

[Gustavo Padovan]

From: Gustavo Padovan 

When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.

Suggested-by: Daniel Stone 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9819fa6..ea7da0e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -42,7 +42,6 @@
  * CPU Interface.
  */

-#define FIMD_DEFAULT_FRAMERATE 60
 #define MIN_FB_WIDTH_FOR_16WORD_BURST 128

 /* position control register for hardware window 0, 2 ~ 4.*/
@@ -329,7 +328,9 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
 {
if (adjusted_mode->vrefresh == 0)
-   adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
+   adjusted_mode->vrefresh = drm_mode_vrefresh(mode);
+   if (adjusted_mode->vrefresh == 0)
+   return false;

return true;
 }
-- 
2.1.0

[PATCH] drm: warn if drivers supporting planar formats try to use drm_fb_get_bpp_depth

[Philipp Zabel]

drm_fb_get_bpp_depth is to be used by legacy drivers only. None of those
support multi-planar formats, so add a WARN_ON if this function is ever
called with a format with more than one plane.

Suggested-by: Daniel Vetter 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/drm_crtc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6112a20..4c5f7d3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5186,6 +5186,12 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
 void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
  int *bpp)
 {
+   /*
+* This function is to be used for legacy drivers only, no new formats
+* formats should be added here.
+*/
+   WARN_ON(drm_format_num_planes(format) != 1);
+
switch (format) {
case DRM_FORMAT_C8:
case DRM_FORMAT_RGB332:
-- 
2.1.4

[PATCH] drm/nouveau/platform: fix compilation if !CONFIG_IOMMU

[Alexandre Courbot]

The lack of IOMMU API support can make nouveau_platform_probe_iommu()
fail to compile because struct iommu_ops is then empty. Fix this by
skipping IOMMU probe in that case - lack of IOMMU on platform devices
is sub-optimal, but is not an error.

Signed-off-by: Alexandre Courbot 
---
This is an alternative to https://lkml.org/lkml/2015/5/19/484. Most users
of Nouveau do not care about IOMMU support, so we should not impose that
option on them.

 drm/nouveau/nouveau_platform.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c 
b/drivers/gpu/drm/nouveau/nouveau_platform.c
index 775277f1edb0..dcfbbfaf1739 100644
--- a/drivers/gpu/drm/nouveau/nouveau_platform.c
+++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
@@ -92,6 +92,8 @@ static int nouveau_platform_power_down(struct 
nouveau_platform_gpu *gpu)
return 0;
 }

+#if IS_ENABLED(CONFIG_IOMMU_API)
+
 static void nouveau_platform_probe_iommu(struct device *dev,
 struct nouveau_platform_gpu *gpu)
 {
@@ -158,6 +160,20 @@ static void nouveau_platform_remove_iommu(struct device 
*dev,
}
 }

+#else
+
+static void nouveau_platform_probe_iommu(struct device *dev,
+struct nouveau_platform_gpu *gpu)
+{
+}
+
+static void nouveau_platform_remove_iommu(struct device *dev,
+ struct nouveau_platform_gpu *gpu)
+{
+}
+
+#endif
+
 static int nouveau_platform_probe(struct platform_device *pdev)
 {
struct nouveau_platform_gpu *gpu;
-- 
2.4.0

[PATCH 6/7] drm: add RGB formats with separate alpha plane

[Daniel Vetter]

On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> Hi Daniel,
> 
> thank you for the comments.
> 
> Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
> [...]
> > > @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > unsigned int *depth,
> > >   break;
> > >   case DRM_FORMAT_RGB565:
> > >   case DRM_FORMAT_BGR565:
> > > + case DRM_FORMAT_RGB565_A8:
> > > + case DRM_FORMAT_BGR565_A8:
> > >   *depth = 16;
> > >   *bpp = 16;
> > >   break;
> > >   case DRM_FORMAT_RGB888:
> > >   case DRM_FORMAT_BGR888:
> > > + case DRM_FORMAT_RGB888_A8:
> > > + case DRM_FORMAT_BGR888_A8:
> > >   *depth = 24;
> > >   *bpp = 24;
> > >   break;
> > > @@ -5210,6 +5222,10 @@ void drm_fb_get_bpp_depth(uint32_t format, 
> > > unsigned int *depth,
> > >   case DRM_FORMAT_XBGR:
> > >   case DRM_FORMAT_RGBX:
> > >   case DRM_FORMAT_BGRX:
> > > + case DRM_FORMAT_XRGB_A8:
> > > + case DRM_FORMAT_XBGR_A8:
> > > + case DRM_FORMAT_RGBX_A8:
> > > + case DRM_FORMAT_BGRX_A8:
> > >   *depth = 24;
> > >   *bpp = 32;
> > >   break;
> > 
> > Please drop the above two hunks, these functions are only for backwards
> > compat with drivers from the addfb1 days. Modern drivers should only use
> > the format tags directly. Extending the plane_cpp function like you do
> > below is enough.
> 
> I'll leave drm_fb_get_bpp_depth untouched.
> 
> > Maybe we should add a WARN_ON(num_planes(format) != 0) to the top of this
> > and a comment that this is for legacy stuff only.
> 
> Do you mean:
> 
> -8<-
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5186,6 +5186,12 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
>  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
> int *bpp)
>  {
> + /*
> +  * This function is to be used for legacy drivers only, no new formats
> +  * should be added here.
> +  */
> + WARN_ON(drm_format_num_planes(format) != 1);
> +
>   switch (format) {
>   case DRM_FORMAT_C8:
>   case DRM_FORMAT_RGB332:
> ->8-

Yeah that looks perfect, please wrap with commit message and I'll
apply.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm/nouveau: Set tile mode

[Alexandre Courbot]

From: Ari Hirvonen 

Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling
mode for imported dma-bufs. This ioctl is staging for now.

Signed-off-by: Ari Hirvonen 
[acourbot at nvidia.com: carry upstream, fix style]
Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/nouveau_drm.c  |  1 +
 drm/nouveau/nouveau_gem.c  | 55 ++
 drm/nouveau/nouveau_gem.h  |  2 ++
 drm/nouveau/uapi/drm/nouveau_drm.h |  8 ++
 4 files changed, 66 insertions(+)

diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
index e4bd6ed51e73..1c7898ec100c 100644
--- a/drm/nouveau/nouveau_drm.c
+++ b/drm/nouveau/nouveau_drm.c
@@ -900,6 +900,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
/* Staging ioctls */
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_SET_TILING, nouveau_gem_ioctl_set_tiling, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 };

 long
diff --git a/drm/nouveau/nouveau_gem.c b/drm/nouveau/nouveau_gem.c
index 0e690bf19fc9..46fa4df0b390 100644
--- a/drm/nouveau/nouveau_gem.c
+++ b/drm/nouveau/nouveau_gem.c
@@ -173,6 +173,61 @@ nouveau_gem_object_close(struct drm_gem_object *gem, 
struct drm_file *file_priv)
 }

 int
+nouveau_gem_ioctl_set_tiling(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   struct nouveau_drm *drm = nouveau_drm(dev);
+   struct nouveau_cli *cli = nouveau_cli(file_priv);
+   struct nvkm_fb *pfb = nvxx_fb(>device);
+   struct drm_nouveau_gem_set_tiling *req = data;
+   struct drm_gem_object *gem;
+   struct nouveau_bo *nvbo;
+   struct nvkm_mem *mem;
+   struct nvkm_vma *vma;
+   int ret = 0;
+
+   if (!pfb->memtype_valid(pfb, req->tile_flags)) {
+   NV_PRINTK(error, cli, "bad memtype: 0x%08x\n", req->tile_flags);
+   return -EINVAL;
+   }
+
+   gem = drm_gem_object_lookup(dev, file_priv, req->handle);
+   if (!gem)
+   return -ENOENT;
+
+   nvbo = nouveau_gem_object(gem);
+
+   if (nvbo->tile_mode != req->tile_mode ||
+   nvbo->tile_flags != req->tile_flags) {
+
+   ret = ttm_bo_reserve(>bo, false, false, false, NULL);
+   if (ret)
+   goto out;
+
+   vma = nouveau_bo_vma_find(nvbo, cli->vm);
+   if (!vma) {
+   ret = -ENOENT;
+   goto unreserve;
+   }
+
+   mem = nvbo->bo.mem.mm_node;
+   nvbo->tile_mode = req->tile_mode;
+   nvbo->tile_flags = req->tile_flags;
+
+   /* Need to rewrite page tables */
+   mem->memtype = (nvbo->tile_flags >> 8) & 0xff;
+   nvkm_vm_map(vma, nvbo->bo.mem.mm_node);
+
+unreserve:
+   ttm_bo_unreserve(>bo);
+   }
+
+out:
+   drm_gem_object_unreference_unlocked(gem);
+   return ret;
+}
+
+int
 nouveau_gem_new(struct drm_device *dev, int size, int align, uint32_t domain,
uint32_t tile_mode, uint32_t tile_flags,
struct nouveau_bo **pnvbo)
diff --git a/drm/nouveau/nouveau_gem.h b/drm/nouveau/nouveau_gem.h
index e4049faca780..56e741d98bcd 100644
--- a/drm/nouveau/nouveau_gem.h
+++ b/drm/nouveau/nouveau_gem.h
@@ -23,6 +23,8 @@ extern void nouveau_gem_object_del(struct drm_gem_object *);
 extern int nouveau_gem_object_open(struct drm_gem_object *, struct drm_file *);
 extern void nouveau_gem_object_close(struct drm_gem_object *,
 struct drm_file *);
+extern int nouveau_gem_ioctl_set_tiling(struct drm_device *, void *,
+   struct drm_file *);
 extern int nouveau_gem_ioctl_new(struct drm_device *, void *,
 struct drm_file *);
 extern int nouveau_gem_ioctl_pushbuf(struct drm_device *, void *,
diff --git a/drm/nouveau/uapi/drm/nouveau_drm.h 
b/drm/nouveau/uapi/drm/nouveau_drm.h
index 4e7e21f41b5c..8f10b16b1473 100644
--- a/drm/nouveau/uapi/drm/nouveau_drm.h
+++ b/drm/nouveau/uapi/drm/nouveau_drm.h
@@ -64,6 +64,12 @@ struct drm_nouveau_gem_new {
uint32_t align;
 };

+struct drm_nouveau_gem_set_tiling {
+   uint32_t handle;
+   uint32_t tile_mode;
+   uint32_t tile_flags;
+};
+
 #define NOUVEAU_GEM_MAX_BUFFERS 1024
 struct drm_nouveau_gem_pushbuf_bo_presumed {
uint32_t valid;
@@ -142,6 +148,7 @@ struct drm_nouveau_gem_cpu_fini {
 #define DRM_NOUVEAU_GEM_INFO   0x44
 /* range 0x98..DRM_COMMAND_END (8 entries) is reserved for staging, unstable 
ioctls */
 #define DRM_NOUVEAU_STAGING_IOCTL  0x58
+#define DRM_NOUVEAU_GEM_SET_TILING (DRM_NOUVEAU_STAGING_IOCTL + 0x0)

 #define DRM_IOCTL_NOUVEAU_GEM_NEWDRM_IOWR(DRM_COMMAND_BASE + 

[PATCH 1/2] drm/nouveau: add staging module option

[Alexandre Courbot]

Add a module option allowing to enable staging/unstable APIs. This will
allow us to experiment freely with experimental APIs for a while before
setting them in stone.

Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/nouveau_drm.c  | 18 ++
 drm/nouveau/uapi/drm/nouveau_drm.h |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
index 89049335b738..e4bd6ed51e73 100644
--- a/drm/nouveau/nouveau_drm.c
+++ b/drm/nouveau/nouveau_drm.c
@@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), 
optimus only default (-1
 int nouveau_runtime_pm = -1;
 module_param_named(runpm, nouveau_runtime_pm, int, 0400);

+MODULE_PARM_DESC(staging, "enable staging APIs");
+int nouveau_staging = 0;
+module_param_named(staging, nouveau_staging, int, 0400);
+
 static struct drm_driver driver_stub;
 static struct drm_driver driver_pci;
 static struct drm_driver driver_platform;
@@ -895,6 +899,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   /* Staging ioctls */
 };

 long
@@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
DRM_DEBUG_DRIVER("... pstate   : %d\n", nouveau_pstate);
+   DRM_DEBUG_DRIVER("... staging  : %d\n", nouveau_staging);
 }

 static const struct dev_pm_ops nouveau_pm_ops = {
@@ -1088,6 +1094,18 @@ err_free:
 static int __init
 nouveau_drm_init(void)
 {
+   /* Do not register staging ioctsl if option not specified */
+   if (!nouveau_staging) {
+   unsigned i;
+
+   /* This keeps us safe is no staging ioctls are defined */
+   i = min(driver_stub.num_ioctls, DRM_NOUVEAU_STAGING_IOCTL);
+   while (!nouveau_ioctls[i - 1].func)
+   i--;
+
+   driver_stub.num_ioctls = i;
+   }
+
driver_pci = driver_stub;
driver_pci.set_busid = drm_pci_set_busid;
driver_platform = driver_stub;
diff --git a/drm/nouveau/uapi/drm/nouveau_drm.h 
b/drm/nouveau/uapi/drm/nouveau_drm.h
index 5507eead5863..4e7e21f41b5c 100644
--- a/drm/nouveau/uapi/drm/nouveau_drm.h
+++ b/drm/nouveau/uapi/drm/nouveau_drm.h
@@ -140,11 +140,14 @@ struct drm_nouveau_gem_cpu_fini {
 #define DRM_NOUVEAU_GEM_CPU_PREP   0x42
 #define DRM_NOUVEAU_GEM_CPU_FINI   0x43
 #define DRM_NOUVEAU_GEM_INFO   0x44
+/* range 0x98..DRM_COMMAND_END (8 entries) is reserved for staging, unstable 
ioctls */
+#define DRM_NOUVEAU_STAGING_IOCTL  0x58

 #define DRM_IOCTL_NOUVEAU_GEM_NEWDRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_NEW, struct drm_nouveau_gem_new)
 #define DRM_IOCTL_NOUVEAU_GEM_PUSHBUFDRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_PUSHBUF, struct drm_nouveau_gem_pushbuf)
 #define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_prep)
 #define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_cpu_fini)
 #define DRM_IOCTL_NOUVEAU_GEM_INFO   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_INFO, struct drm_nouveau_gem_info)
+/* staging ioctls */

 #endif /* __NOUVEAU_DRM_H__ */
-- 
2.4.0

[PATCH 0/2] drm/nouveau: option for staging ioctls and new SET_TILING ioctl

[Alexandre Courbot]

This patchset proposes to introduce a "staging" module option to dynamically
enable features (mostly ioctls) that are merged but may be refined before
they are declared "stable". The second patch illustrates the use of this
staging option with the SET_TILING ioctl, which can be used to specify the
tiling options of a PRIME-imported buffer.

The staging parameter will allow us (especially, us at NVIDIA) to experiment
more freely with new features and avoid carrying patches across version. To
prevent abuse, the number of staging IOCTLs is limited to 8 (range 0x98 to
0xa0) that are to be recycled as staging IOCTLs become stable and are assigned
a final number.

Alexandre Courbot (1):
  drm: add staging module option

Ari Hirvonen (1):
  drm/nouveau: Set tile mode

 drm/nouveau/nouveau_drm.c  | 19 +
 drm/nouveau/nouveau_gem.c  | 55 ++
 drm/nouveau/nouveau_gem.h  |  2 ++
 drm/nouveau/uapi/drm/nouveau_drm.h | 11 
 4 files changed, 87 insertions(+)

-- 
2.4.0

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

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

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

pstglia at gmail.com changed:

   What|Removed |Added

   Priority|medium  |low

-- 
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/20150520/9076ab82/attachment.html>

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

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

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

--- Comment #1 from pstglia at gmail.com ---
Additional Notes:
 - Mesa version tested is 10.5.4
 - libdrm version used is 2.4.61
 - kernel version tested are 4.0 and 4.0.3
 - llvm version is 3.5.0svn (used by AOSP)

Hardwares tested: 
 - AMD E1 2100 (KANIBI)
 - AMD R7 240 (OLAND)

-- 
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/20150520/92cb0a96/attachment.html>

[RFC PATCH v2] perf: Add PERF_EVENT_IOC_FLUSH ioctl

[Ingo Molnar]

* Robert Bragg  wrote:

> To allow for pmus that may have internal buffering (e.g. the hardware
> itself writes out data to its own circular buffer which is only
> periodically forwarded to userspace via perf) this ioctl enables
> userspace to explicitly ensure it has received all samples before a
> point in time.
> 
> v2: return int error status
> 
> Signed-off-by: Robert Bragg 
> ---
>  include/linux/perf_event.h  | 7 +++
>  include/uapi/linux/perf_event.h | 1 +
>  kernel/events/core.c| 5 +
>  3 files changed, 13 insertions(+)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index cf1d096..0c591eb 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -305,6 +305,13 @@ struct pmu {
>* Free pmu-private AUX data structures
>*/
>   void (*free_aux)(void *aux); /* optional */
> +
> + /*
> +  * Flush buffered samples (E.g. for pmu hardware that writes samples to
> +  * some intermediate buffer) userspace may need to explicitly ensure
> +  * such samples have been forwarded to perf.
> +  */
> + int (*flush)(struct perf_event *event); /*optional 
> */
>  };
>  
>  /**
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 309211b..cbf1b80 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -389,6 +389,7 @@ struct perf_event_attr {
>  #define PERF_EVENT_IOC_SET_FILTER_IOW('$', 6, char *)
>  #define PERF_EVENT_IOC_ID_IOR('$', 7, __u64 *)
>  #define PERF_EVENT_IOC_SET_BPF   _IOW('$', 8, __u32)
> +#define PERF_EVENT_IOC_FLUSH _IO ('$', 9)
>  
>  enum perf_event_ioc_flags {
>   PERF_IOC_FLAG_GROUP = 1U << 0,
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 3fe532a..72daee6 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4079,6 +4079,11 @@ static long _perf_ioctl(struct perf_event *event, 
> unsigned int cmd, unsigned lon
>   case PERF_EVENT_IOC_SET_BPF:
>   return perf_event_set_bpf_prog(event, arg);
>  
> + case PERF_EVENT_IOC_FLUSH:
> + if (event->pmu->flush)
> + return event->pmu->flush(event);
> + return 0;
> +
>   default:
>   return -ENOTTY;
>   }

So 'struct file_operations' has a callback for:

int (*fsync) (struct file *, loff_t, loff_t, int datasync);

Could we use that perhaps, instead of an ioctl()? Not sure how it all 
integrates with the VFS though.

Thanks,

Ingo

[PATCH] nouveau: add coherent BO attribute

[Alexandre Courbot]

On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
 wrote:
> Op 15-05-15 om 09:11 schreef Alexandre Courbot:
>> Re-pinging Marteen on an email address that still exists :P
>>
>> On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot  
>> wrote:
>>> On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot  
>>> wrote:
 On 03/14/2015 04:33 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 13-03-15 om 07:27 schreef Alexandre Courbot:
>> Add a flag allowing Nouveau to specify that an object should be coherent
>> at allocation time. This is required for some class of objects like
>> fences which are randomly-accessed by both the CPU and GPU. This flag
>> instructs the kernel driver to make sure the object remains coherent
>> even on architectures for which coherency is not guaranteed by the bus.
>>
>> Signed-off-by: Alexandre Courbot 
> I don't see a problem with this patch, but similar patches to intel to
> libdrm have been shot down when the changes weren't in an official kernel
> yet, so I think this should wait until the change is at least in drm-next.
> ;-)

 Sounds good. I will ping you again once the kernel change reaches -next.
>>> Hi Marteen,
>>>
>>> The kernel change required for this patch is now in -next. Do you
>>> think we can merge it now?
> I think it would be ok to merge now.

Great - who could do this? :P

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

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

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

Bug ID: 90537
   Summary: radeonsi bo/va conflict on RADEON_GEM_VA
(rscreen->ws->buffer_from_handle returns NULL)
   Product: Mesa
   Version: 10.5
  Hardware: x86 (IA32)
OS: other
Status: NEW
  Severity: trivial
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: pstglia at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 115927
  --> https://bugs.freedesktop.org/attachment.cgi?id=115927=edit
dmesg output (drm.debug=7)

Hi, we're trying to make radeonsi work on Android-x86 (porting of AOSP to x86
architecture).

We can have graphical output, but at some circunstances (certain apps, like
Antutu Benchmark) we are receiving a "radeon bo/va conflict with bo/va" from
kernel. When this happens, graphical components crashes.

As I could check, This error occurs on "r600_texture_from_handle" (which is
being called on native_android.cpp gallium state tracker;
screen->resource_from_handle - use_drm is set ) 

When calling "rscreen->ws->buffer_from_handle" NULL is being returned. From
kernel dmesg (drm.debug = 7), we get this ioctl error:

...
<7>[  244.847256] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0,
DRM_IOCTL_GEM_CLOSE
<7>[  244.847269] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0,
DRM_IOCTL_GEM_CLOSE
<7>[  244.848972] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
RADEON_GEM_CREATE
<7>[  244.849030] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_VA
<7>[  244.849084] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_MMAP
<7>[  244.849150] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
RADEON_GEM_CREATE
<7>[  244.849177] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_VA
<3>[  244.849191] radeon :00:01.0: bo ccf78800 va 0x000858 conflict
with (bo cec3a000 0x000869 0x00086a)
<7>[  244.849199] [drm:drm_ioctl] ret = -22
<7>[  244.849251] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
DRM_IOCTL_GEM_CLOSE
<7>[  244.853770] [drm:drm_release] open_count = 5
<7>[  244.853782] [drm:drm_release] pid = 3464, device = 0xe200, open_count = 5
...

I suppose this "buffer_from_handle" in this case is mapped with
"radeon_winsys_bo_from_handle" function. If this assumption is correct, the
error is occuring during this call:


va.handle = bo->handle;
va.operation = RADEON_VA_MAP;
va.vm_id = 0;
va.offset = bo->va;
va.flags = RADEON_VM_PAGE_READABLE |
   RADEON_VM_PAGE_WRITEABLE |
   RADEON_VM_PAGE_SNOOPED;
va.offset = bo->va;
r = drmCommandWriteRead(ws->fd, DRM_RADEON_GEM_VA, , sizeof(va));
if (r && va.operation == RADEON_VA_RESULT_ERROR) {
fprintf(stderr, "radeon: Failed to assign virtual address
space\n");
radeon_bo_destroy(>base);
return NULL;

I tried using kernel 4.0.3 (which contains some kernel patches apparently
related to this):

drm/radeon: fix lockup when BOs aren't part of the VM on release 
drm/radeon: reset BOs address after clearing it. 
drm/radeon: check new address before removing old one 

But the same error happens.

I'd like some help in order to find out what's wrong (bug on Mesa/drm or wrong
config at Android side):

- I'm building for a 32 bits environment. Does this can cause the problem I
described? Maybe the driver/drm/mesa works better on a 64 bits environment?

- For graphical buffer management (alloc, map, unmap, etc) we have drm_gralloc,
which is based on xf86-video-ati. If possible, can you take a quick look an see
if there's something that needs to changed in particullar for
radeonsi?(gralloc_drm_radeon.c on
http://git.android-x86.org/?p=platform/hardware/drm_gralloc.git;a=tree;h=refs/heads/lollipop-x86;hb=refs/heads/lollipop-x86)

Any help is appreciated. Thank you!
pstglia

ps: It's working nice with r600g driver/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/20150520/9be9c29e/attachment.html>

[PATCH] drm/nouveau/platform: fix compilation if !CONFIG_IOMMU

[Arnd Bergmann]

On Wednesday 20 May 2015 13:32:33 Thierry Reding wrote:
> 
> Since these are all static functions, perhaps an "if (IS_ENABLED(...))"
> would work here? That way you'd get compile coverage of the code in all
> cases.

I had the same thought at first.

> But perhaps that doesn't work for IOMMU. I have a vague memory of
> running across something like this before and IOMMU has this quirk of
> defining struct iommu_ops as empty if IOMMU_API is deselected so you'll
> probably get compiler errors unless you actually preprocess the code
> out.

Exactly.

Arnd

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

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

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

--- Comment #6 from acab at digitalfuture.it ---
(In reply to Michel Dänzer from comment #5)
> Can you try isolating the LLVM change introducing it with git bisect? Note
> that this might require some tweaking because current Mesa might fail to
> build against some development snapshots of LLVM.

Yes I could, however upsteam appears to maintain llvm in svn.
There is a git repository as well but it lacks branches and tags.

Additionally the branch history doesn't look very linear and so far i've failed
to match the proper commit from the branch in master.
For example the top commit in
http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_352/final is:

r214336 | rafael.espindola | 2014-07-30 17:04:00 -0400 (Wed, 30 Jul 2014) | 9
lines

SimplifyCFG: Avoid miscompilations due to removed lifetime intrinsics.

Which appears to match commit 7fef5a3d1907c813712fcb2a44d8187a65ba08cd:
Author: Rafael Espindola 
Date:   Wed Jul 30 21:04:00 2014 +

SimplifyCFG: Avoid miscompilations due to removed lifetime intrinsics.


However mesa 10.5.5 doesn't build against that llvm (doesn't like
TM->getSubtargetImpl()->getInstrInfo() in lp_bld_debug.cpp), but it does build
against 3.5.2.


Can you suggest some commit ids i could use as good and bad markers?

-- 
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/20150520/8f7bd80c/attachment.html>

[Bug 90263] GPU card fans run full speed at all times

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

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

--- Comment #12 from Alex Deucher  ---
(In reply to Todd from comment #11)
> I was expecting this problem to be solved through the miracle of "dynamic
> power management support" brought down from the mountain of Linux 4.
> 
> I had assumed that the GPU was running at full power all the time under the
> Linux Radeon driver, hence the loud fans. When booted to Windows 7, the card
> is quiet.
> 
> Is fan speed control a different issue? I'm losing track of what this issue
> is a symptom of and where to correctly report the bug.

Power management support has been available and enabled by default for your
card for a while now (since 3.12 or so IIRC).  The driver properly controls the
clocks and voltages on your card.  The fan control is somewhat independent. 
For most cards of this generation, the vbios sets up the fan profile to scale
the fan based on GPU temperature and the driver just uses that.  You happen to
have a card with a limited vbios fan profile that requires the driver to set up
smc fan control.

-- 
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/20150520/7d4213a4/attachment.html>

[PATCH] drm/nouveau/platform: fix compilation if !CONFIG_IOMMU

[Thierry Reding]

On Wed, May 20, 2015 at 03:10:24PM +0900, Alexandre Courbot wrote:
> The lack of IOMMU API support can make nouveau_platform_probe_iommu()
> fail to compile because struct iommu_ops is then empty. Fix this by
> skipping IOMMU probe in that case - lack of IOMMU on platform devices
> is sub-optimal, but is not an error.
> 
> Signed-off-by: Alexandre Courbot 
> ---
> This is an alternative to https://lkml.org/lkml/2015/5/19/484. Most users
> of Nouveau do not care about IOMMU support, so we should not impose that
> option on them.
> 
>  drm/nouveau/nouveau_platform.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c 
> b/drivers/gpu/drm/nouveau/nouveau_platform.c
> index 775277f1edb0..dcfbbfaf1739 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_platform.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
> @@ -92,6 +92,8 @@ static int nouveau_platform_power_down(struct 
> nouveau_platform_gpu *gpu)
>   return 0;
>  }
>  
> +#if IS_ENABLED(CONFIG_IOMMU_API)
> +
>  static void nouveau_platform_probe_iommu(struct device *dev,
>struct nouveau_platform_gpu *gpu)
>  {
> @@ -158,6 +160,20 @@ static void nouveau_platform_remove_iommu(struct device 
> *dev,
>   }
>  }
>  
> +#else
> +
> +static void nouveau_platform_probe_iommu(struct device *dev,
> +  struct nouveau_platform_gpu *gpu)
> +{
> +}
> +
> +static void nouveau_platform_remove_iommu(struct device *dev,
> +   struct nouveau_platform_gpu *gpu)
> +{
> +}
> +
> +#endif
> +

Since these are all static functions, perhaps an "if (IS_ENABLED(...))"
would work here? That way you'd get compile coverage of the code in all
cases.

But perhaps that doesn't work for IOMMU. I have a vague memory of
running across something like this before and IOMMU has this quirk of
defining struct iommu_ops as empty if IOMMU_API is deselected so you'll
probably get compiler errors unless you actually preprocess the code
out.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/b2177925/attachment.sig>

[Intel-gfx] [PATCH] Documentation/drm: Update rotation property with 90/270 and description

[Jindal, Sonika]

On 5/13/2015 9:57 AM, Jindal, Sonika wrote:
>
>
> On 5/12/2015 6:20 PM, Ville Syrjälä wrote:
>> On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:
>>> Cc: dri-devel at lists.freedesktop.org
>>> Signed-off-by: Sonika Jindal 
>>> ---
>>>   Documentation/DocBook/drm.tmpl |7 +--
>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/DocBook/drm.tmpl
>>> b/Documentation/DocBook/drm.tmpl
>>> index f4976cd..266d50a 100644
>>> --- a/Documentation/DocBook/drm.tmpl
>>> +++ b/Documentation/DocBook/drm.tmpl
>>> @@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
>>>   Plane
>>>   “rotation”
>>>   BITMASK
>>> -{ 0, "rotate-0" }, { 2, "rotate-180" }
>>> +{ 0, "rotate-0" }, { 1, "rotate-90" },
>>> +{ 2, "rotate-180" }, { 3, "rotate-270" }
>>>   Plane
>>> -TBD
>>> +To set plane HW rotation. This rotation
>>> property does
>>> +the plane rotation in counter clockwise direction which is
>>> +inline with the way XRandr works.
>>
>> I would suggest moving the thing to the generci props section since we
>> have omap and i915 both supporting it.
> You mean in DRM properties section?
> Right now, OMAP section also has rotation property. I will remove it
> from OMAP section as well if you think drm is the better place.
>
>>
>> As for the description, we should also document the reflect flags.
>>
i915 doesn't support reflect flags. It only create rotation property 
with rotation flags.

For "generic" section, you mean moving to generic group of properties in 
i915 only right?
>> I might write it as something like this:
>> "rotate-0,rotate-90,rotate-180,rotate-270 rotate the image by the
>> specified amount in degrees in a counter clockwise direction.
>> reflect-x,reflect-y reflect the image along the specified axis,
>> prior to rotation."
>>
>>>   
>>>   
>>>   SDVO-TV
>>> --
>>> 1.7.10.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>

[PATCH 7/7] drm/imx: ipuv3-plane: add support for separate alpha planes

[Philipp Zabel]

Am Dienstag, den 19.05.2015, 18:58 +0200 schrieb Daniel Vetter:
[...]
> > @@ -86,13 +93,36 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, 
> > struct drm_framebuffer *fb,
> > eba = cma_obj->paddr + fb->offsets[0] +
> >   fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
> >  
> > +   switch (fb->pixel_format) {
> > +   case DRM_FORMAT_RGB565_A8:
> > +   case DRM_FORMAT_BGR565_A8:
> > +   case DRM_FORMAT_RGB888_A8:
> > +   case DRM_FORMAT_BGR888_A8:
> > +   case DRM_FORMAT_RGBX_A8:
> > +   case DRM_FORMAT_BGRX_A8:
> > +   alpha_eba = cma_obj->paddr + fb->offsets[1] +
> > +   fb->pitches[1] * y + x;
> 
> You need to look at the 2nd cma_obj here, i.e. drm_fb_cma_get_gem_obj(fb, 1);
> 
> Yes, userspace is allowed to hand in non-matching. And given that you
> you just reuse the cma helpers and don't reject framebuffers with
> non-matching cma objects your current planar yuv support is also already
> broken. Would be good if you could also patch modetest a bit to exercise
> this ...
> -Daniel

Ow, right. I'll have a look at this.

thanks
Philipp

[PATCH 6/7] drm: add RGB formats with separate alpha plane

[Philipp Zabel]

Hi Daniel,

thank you for the comments.

Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
[...]
> > @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned 
> > int *depth,
> > break;
> > case DRM_FORMAT_RGB565:
> > case DRM_FORMAT_BGR565:
> > +   case DRM_FORMAT_RGB565_A8:
> > +   case DRM_FORMAT_BGR565_A8:
> > *depth = 16;
> > *bpp = 16;
> > break;
> > case DRM_FORMAT_RGB888:
> > case DRM_FORMAT_BGR888:
> > +   case DRM_FORMAT_RGB888_A8:
> > +   case DRM_FORMAT_BGR888_A8:
> > *depth = 24;
> > *bpp = 24;
> > break;
> > @@ -5210,6 +5222,10 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned 
> > int *depth,
> > case DRM_FORMAT_XBGR:
> > case DRM_FORMAT_RGBX:
> > case DRM_FORMAT_BGRX:
> > +   case DRM_FORMAT_XRGB_A8:
> > +   case DRM_FORMAT_XBGR_A8:
> > +   case DRM_FORMAT_RGBX_A8:
> > +   case DRM_FORMAT_BGRX_A8:
> > *depth = 24;
> > *bpp = 32;
> > break;
> 
> Please drop the above two hunks, these functions are only for backwards
> compat with drivers from the addfb1 days. Modern drivers should only use
> the format tags directly. Extending the plane_cpp function like you do
> below is enough.

I'll leave drm_fb_get_bpp_depth untouched.

> Maybe we should add a WARN_ON(num_planes(format) != 0) to the top of this
> and a comment that this is for legacy stuff only.

Do you mean:

-8<-
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5186,6 +5186,12 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
 void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
  int *bpp)
 {
+   /*
+* This function is to be used for legacy drivers only, no new formats
+* should be added here.
+*/
+   WARN_ON(drm_format_num_planes(format) != 1);
+
switch (format) {
case DRM_FORMAT_C8:
case DRM_FORMAT_RGB332:
->8-

> lgtm otherwise.
> -Daniel

regards
Philipp

[PATCH 04/12] drm/radeon: Use DECLARE_BITMAP

[Alex Deucher]

On Tue, May 19, 2015 at 9:37 PM, Joe Perches  wrote:
> Use the generic mechanism to declare a bitmap instead of unsigned long.
>
> Signed-off-by: Joe Perches 

Applied to my -next tree.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 46eb0fa..d556733 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -719,7 +719,7 @@ struct radeon_doorbell {
> resource_size_t size;
> u32 __iomem *ptr;
> u32 num_doorbells;  /* Number of doorbells 
> actually reserved for radeon. */
> -   unsigned long   used[DIV_ROUND_UP(RADEON_MAX_DOORBELLS, 
> BITS_PER_LONG)];
> +   DECLARE_BITMAP(used, RADEON_MAX_DOORBELLS);
>  };
>
>  int radeon_doorbell_get(struct radeon_device *rdev, u32 *page);
> --
> 2.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

[Archit Taneja]

On 05/20/2015 12:05 PM, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 10:49:38AM +0530, Archit Taneja wrote:
>> On 05/19/2015 09:00 PM, Daniel Vetter wrote:
>>> On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
 On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
>> +void drm_bridge_post_disable(struct drm_bridge *bridge)
>> +{
>> +if (!bridge)
>> +return;
>> +
>> +drm_bridge_post_disable(bridge->next);
>> +
>> +bridge->funcs->post_disable(bridge);
>
> For symmetry I'd call the post_disable hook for the next brigde _after_
> this one. Otherwise we break abstraction. E.g. with 1 bridge we'd have
>
> bridgeA_disable();
> encoder_disable();
> bridgeA_post_disable();
>
> But if on some other part bridge A is connected to bridge B (i.e. we
> replace the encoder with a combo of other_encoder+bridgeA) with your code
> the post_disable is suddenly interleaved with the preceeding stages in the
> pipeline:
>
>
> bridgeA_disable();
> bridgeB_disable();
> other_encoder_disable();
> bridgeA_post_disable();
> bridgeB_post_disable();
>
> Which means from the pov of bridgeA there's a difference between whether
> it's connected to "encoder" or "other_encoder+bridgeB". But if we reorder
> the post_disable sequence like I suggest we'll get:
>
> bridgeA_disable();
> bridgeB_disable();
> other_encoder_disable();
> bridgeB_post_disable();
> bridgeA_post_disable();
>
> Which means that "encoder" and "other_encoder+bridgeB" look the same for
> bridgeA. To avoid confusion the two pipelines in hw are:
>
> encoder ---> bridgeA
>
> other_encoder ---> bridgeB ---> bridgeA

 I agree with this, thanks for the explanation. Although, I'm not sure about
 the pre_enable part below.

 

>> +void drm_bridge_pre_enable(struct drm_bridge *bridge)
>> +{
>> +if (!bridge)
>> +return;
>> +
>> +bridge->funcs->pre_enable(bridge);
>> +
>> +drm_bridge_pre_enable(bridge->next);
>
> Same as with post_disable, pre_enable for bridge->next should be called
> _before_ the pre_enable for this bridge.


 The order of nesting suggested by you gives the sequence:

 bridgeA_pre_enable();
 bridgeB_pre_enable();
 other_encoder_enable();
 bridgeB_enable();
 bridgeA_enable();

 This won't work if the bridge A relies on bridge B to be enabled first. 
 This
 happens in the encoder path I'm working on:

 msm mdp5 encoder -> dsi bridge -> adv7511 dsi to hdmi bridge chip


 The adv chip relies on dsi's clock for it to function. If dsi's 
 pre_enable()
 isn't called first, then adv's pre_enable would fail.
>>>
>>> If you need the clock, then imo that's code which should be in the enable
>>> hook, and not in the pre-enable hook. At least thus far the rules have
>>> roughly been:
>>> - pre_enable: anything that needs to be done _before_ clock+timings are
>>>enabled by the source for this bridge.
>>> - enable: anything that needs clock+timings to be on from the source for
>>>this bridge.
>>
>> Okay. I think I got the rules wrong. I assumed that pre_enable() should do
>> the heavy enabling. This happened because I was looking at the
>> bridges(dsi/hdmi/edp) in msm as reference. Those were actually a special
>> case, where the bridge feeds back the pixel clock to the mdp encoder. That's
>> why everything was stuffed within pre_enable. They can afford to not comply
>> to the rules since they are tightly coupled with the msm driver.
>>
>>>
>>> Similar for the disable side:
>>> - disable still has clocks+timing on.
>>> - post_disable should be called after clocks are off.
>>>
>>> In i915 we once had a callback in between clock enabling and timing
>>> enabling, but we've removed that again after some restructuring. Maybe we
>>> need such a hook bridges? But that also means we need to split up
>>> encoder/crtc callbacks, and that will get nasty real fast.
>>
>> Yeah, let's stay away from that!
>>
>>>
 We could modify the call order in drm_bridge_enable() instead to achieve:

 bridgeB_pre_enable();
 bridgeA_pre_enable();
 other_encoder_enable();
 bridgeA_enable();
 bridgeB_enable();

 This fixes the sequence for pre_enable() calls, but assumes that the
 configurations in the enable() don't need to follow a specific sequence to
 ensure proper behavior.

 pre_enable() should ideally represent things to be done before we enable 
 the
 next encoder in the chain. So the sequence right above seems to be better.
>>>
>>> Nah, that's even more backwards imo. From bridgeA's pov it really should
>>> make no difference at all whether the input is 

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

[Rob Clark]

On Wed, May 20, 2015 at 11:32 AM, Daniel Vetter  wrote:
> On Wed, May 20, 2015 at 11:15:27AM -0400, Rob Clark wrote:
>> Using fb modifier flag, support NV12MT format in MDP4.
>>
>> v2:
>> - rework the modifier's description [Daniel Vetter's comment]
>> - drop .set_mode_config() callback [Rob Clark's comment]
>> v3:
>> - change VENDOR's name and restrict usage to NV12 [pointed by Daniel]
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/drm_crtc.c| 14 ++
>>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
>>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
>>  include/uapi/drm/drm_fourcc.h | 15 +++
>>  4 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 3007b44..ed5d3f9 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -3304,6 +3304,20 @@ static int framebuffer_check(const struct 
>> drm_mode_fb_cmd2 *r)
>> r->modifier[i], i);
>>   return -EINVAL;
>>   }
>> +
>> + /* modifier specific checks: */
>> + switch (r->modifier[i]) {
>> + case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
>> + if (r->pixel_format != DRM_FORMAT_NV12 ||
>> + width % 128 || height % 32) {
>> + DRM_DEBUG_KMS("bad modifier data for plane 
>> %d\n", i);
>> + return -EINVAL;
>> + }
>
> Should we also check that the stride matches the macroblock size? lgtm
> otherwise.

I don't believe we have any restriction on stride.. although I can add
a check for multiple of 128 now and revisit when some other driver(s)
support the format.  Probably better to relax restrictions later,
rather than other way around.

BR,
-R

> -Daniel
>
>> + break;
>> +
>> + default:
>> + break;
>> + }
>>   }
>>
>>   return 0;
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
>> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
>> index d847b94..88a75cb 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
>> @@ -119,6 +119,8 @@ static int mdp4_hw_init(struct msm_kms *kms)
>>   if (mdp4_kms->rev > 1)
>>   mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
>>
>> + dev->mode_config.allow_fb_modifiers = true;
>> +
>>  out:
>>   pm_runtime_put_sync(dev->dev);
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
>> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
>> index dbc0689..0d1dbb7 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
>> @@ -33,6 +33,21 @@ struct mdp4_plane {
>>  };
>>  #define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)
>>
>> +/* MDP format helper functions */
>> +static inline
>> +enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
>> +{
>> + bool is_tile = false;
>> +
>> + if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
>> + is_tile = true;
>> +
>> + if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
>> + return FRAME_TILE_YCBCR_420;
>> +
>> + return FRAME_LINEAR;
>> +}
>> +
>>  static void mdp4_plane_set_scanout(struct drm_plane *plane,
>>   struct drm_framebuffer *fb);
>>  static int mdp4_plane_mode_set(struct drm_plane *plane,
>> @@ -205,6 +220,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
>>   uint32_t op_mode = 0;
>>   uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
>>   uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
>> + enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);
>>
>>   if (!(crtc && fb)) {
>>   DBG("%s: disabled!", mdp4_plane->name);
>> @@ -304,6 +320,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
>>   MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count 
>> - 1) |
>>   MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type) |
>>   
>> MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample) |
>> + MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
>>   COND(format->unpack_tight, 
>> MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));
>>
>>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
>> @@ -324,6 +341,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
>>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
>>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);
>>
>> + if (frame_type != FRAME_LINEAR)
>> + mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
>> + MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
>> + 

[Intel-gfx] [PATCH] Documentation/drm: Update rotation property with 90/270 and description

[Jindal, Sonika]

On 5/13/2015 9:57 AM, Jindal, Sonika wrote:
>
>
> On 5/12/2015 6:20 PM, Ville Syrjälä wrote:
>> On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:
>>> Cc: dri-devel at lists.freedesktop.org
>>> Signed-off-by: Sonika Jindal 
>>> ---
>>>   Documentation/DocBook/drm.tmpl |7 +--
>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/DocBook/drm.tmpl
>>> b/Documentation/DocBook/drm.tmpl
>>> index f4976cd..266d50a 100644
>>> --- a/Documentation/DocBook/drm.tmpl
>>> +++ b/Documentation/DocBook/drm.tmpl
>>> @@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
>>>   Plane
>>>   “rotation”
>>>   BITMASK
>>> -{ 0, "rotate-0" }, { 2, "rotate-180" }
>>> +{ 0, "rotate-0" }, { 1, "rotate-90" },
>>> +{ 2, "rotate-180" }, { 3, "rotate-270" }
>>>   Plane
>>> -TBD
>>> +To set plane HW rotation. This rotation
>>> property does
>>> +the plane rotation in counter clockwise direction which is
>>> +inline with the way XRandr works.
>>
>> I would suggest moving the thing to the generci props section since we
>> have omap and i915 both supporting it.
> You mean in DRM properties section?
> Right now, OMAP section also has rotation property. I will remove it
> from OMAP section as well if you think drm is the better place.
>
>>
>> As for the description, we should also document the reflect flags.
>>
Also, i915 doesn't support reflect flags. Only rotation is supported there.
For the "generic" part, you meant just moving to the generic group in 
i915 property section?
>> I might write it as something like this:
>> "rotate-0,rotate-90,rotate-180,rotate-270 rotate the image by the
>> specified amount in degrees in a counter clockwise direction.
>> reflect-x,reflect-y reflect the image along the specified axis,
>> prior to rotation."
>>
>>>   
>>>   
>>>   SDVO-TV
>>> --
>>> 1.7.10.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>

[PATCH] drm/plane-helper: Adapt cursor hack to transitional helpers

[Pekka Paalanen]

On Wed, 20 May 2015 10:36:32 +0200
Daniel Vetter  wrote:

> In
> 
> commit f02ad907cd9e7fe3a6405d2d005840912f1ed258
> Author: Daniel Vetter 
> Date:   Thu Jan 22 16:36:23 2015 +0100
> 
> drm/atomic-helpers: Recover full cursor plane behaviour
> 
> we've added a hack to atomic helpers to never to vblank waits for
> cursor updates through the legacy apis since that's what X expects.
> Unfortunately we've (again) forgotten to adjust the transitional
> helpers. Do this now.
> 
> This fixes regressions for drivers only partially converted over to
> atomic (like i915).
> 
> Reported-by: Pekka Paalanen 
> Cc: Pekka Paalanen 
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_plane_helper.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 40c1db9ad7c3..2f0ed11024eb 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -465,6 +465,9 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>   if (!crtc[i])
>   continue;
>  
> + if (crtc[i]->cursor == plane)
> + continue;
> +
>   /* There's no other way to figure out whether the crtc is 
> running. */
>   ret = drm_crtc_vblank_get(crtc[i]);
>   if (ret == 0) {

Hi,

just adding more people to CC who might want to test this.

When you test this, please make sure your Weston does *NOT* have this
patch:
http://cgit.freedesktop.org/wayland/weston/commit/?id=6858383d51b12632481370fdc7d886a1e6bb4ebd

That is, use Weston 1.7.92 or earlier.


Thanks,
pq

4.1-rc4 display-port on radeon not working

[Alex Deucher]

On Tue, May 19, 2015 at 6:03 PM, Malte Schröder  wrote:
> Hi,
> with 4.1-rc display-port on my Tahiti XT stopped working. I used the
> firmware from http://people.freedesktop.org/~agd5f/radeon_ucode/ as of
> today.
> Note: the display is an Asus PB278, it used to have problems with
> display port negotiation, but those disappeared like a year ago.
>

Does booting with radeon.auxch=0 on the kernel command line in grub
help?  Can you bisect?

Alex

[PATCH] drm/panel: Add bus format for HannStar HSD100PXN1

[Philipp Zabel]

This patch adds the bus_format field to the HSD100PXN1 panel structure.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 63dea57..28d7360 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -759,6 +759,7 @@ static const struct panel_desc hannstar_hsd100pxn1 = {
.width = 203,
.height = 152,
},
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
 };

 static const struct drm_display_mode hitachi_tx23d38vm0caa_mode = {
-- 
2.1.4

[PATCH 2/2] drm/exynos: WARN_ON if ideal_clk is zero

[Gustavo Padovan]

From: Gustavo Padovan 

ideal_clk is the divisor in an operation to find the clock divider so
it can't never be zero or we will end up with a division by zero error.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 08f7197..294f9cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -309,6 +309,8 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
u32 clkdiv;

+   WARN_ON(ideal_clk == 0);
+
if (ctx->i80_if) {
/*
 * The frame done interrupt should be occurred prior to the
-- 
2.1.0

[PATCH 1/2] drm/exynos: calculate vrefresh instead of use a fixed value

[Gustavo Padovan]

From: Gustavo Padovan 

When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9819fa6..08f7197 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -42,7 +42,6 @@
  * CPU Interface.
  */

-#define FIMD_DEFAULT_FRAMERATE 60
 #define MIN_FB_WIDTH_FOR_16WORD_BURST 128

 /* position control register for hardware window 0, 2 ~ 4.*/
@@ -329,7 +328,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
 {
if (adjusted_mode->vrefresh == 0)
-   adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
+   adjusted_mode->vrefresh = drm_mode_vrefresh(mode);

return true;
 }
-- 
2.1.0

[PATCH] drm/msm/mdp5: fix incorrect parameter for msm_framebuffer_iova()

[Rob Clark]

On Wed, May 20, 2015 at 10:57 AM, Stephane Viau  wrote:
> The index of ->planes[] array (3rd parameter) cannot be equal to MAX_PLANE.
> This looks like a typo that is now fixed.
>
> Signed-off-by: Stephane Viau 

Acked-by: Rob Clark 

Dave, since it looks like you've merged my earlier fixes pull but
haven't sent to linus yet, do you mind applying this one directly on
msm-fixes?

BR,
-R

> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 18a3d20..57b8f56 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -273,7 +273,7 @@ static void set_scanout_locked(struct drm_plane *plane,
> mdp5_write(mdp5_kms, REG_MDP5_PIPE_SRC2_ADDR(pipe),
> msm_framebuffer_iova(fb, mdp5_kms->id, 2));
> mdp5_write(mdp5_kms, REG_MDP5_PIPE_SRC3_ADDR(pipe),
> -   msm_framebuffer_iova(fb, mdp5_kms->id, 4));
> +   msm_framebuffer_iova(fb, mdp5_kms->id, 3));
>
> plane->fb = fb;
>  }
> --
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>

Experiencing FIFO underruns on Intel Skylake platform

[Jani Nikula]

On Wed, 20 May 2015, Rainer Koenig  wrote:
> Am 19.05.2015 um 13:41 schrieb Jani Nikula:
>> 
>> +intel-gfx
>
>> For brand new platforms you should be running drm-intel-nightly branch
>> from http://cgit.freedesktop.org/drm-intel.
>
> Tested now, drm-intel-nightly solves the problem.
>
> Thanks a lot

Great, thanks for reporting back.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

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

[Rob Clark]

On Wed, May 20, 2015 at 11:15 AM, Rob Clark  wrote:
> Using fb modifier flag, support NV12MT format in MDP4.
>
> v2:
> - rework the modifier's description [Daniel Vetter's comment]
> - drop .set_mode_config() callback [Rob Clark's comment]
> v3:
> - change VENDOR's name and restrict usage to NV12 [pointed by Daniel]
>
> Signed-off-by: Rob Clark 

jfwiw, this will depend on a 'regenerate headers' patch (with couple
other regs renamed at the same time).. so if ack'd it probably makes
more sense for me to include w/ msm pull req

BR,
-R

> ---
>  drivers/gpu/drm/drm_crtc.c| 14 ++
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
>  include/uapi/drm/drm_fourcc.h | 15 +++
>  4 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3007b44..ed5d3f9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3304,6 +3304,20 @@ static int framebuffer_check(const struct 
> drm_mode_fb_cmd2 *r)
>   r->modifier[i], i);
> return -EINVAL;
> }
> +
> +   /* modifier specific checks: */
> +   switch (r->modifier[i]) {
> +   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
> +   if (r->pixel_format != DRM_FORMAT_NV12 ||
> +   width % 128 || height % 32) {
> +   DRM_DEBUG_KMS("bad modifier data for plane 
> %d\n", i);
> +   return -EINVAL;
> +   }
> +   break;
> +
> +   default:
> +   break;
> +   }
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index d847b94..88a75cb 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -119,6 +119,8 @@ static int mdp4_hw_init(struct msm_kms *kms)
> if (mdp4_kms->rev > 1)
> mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
>
> +   dev->mode_config.allow_fb_modifiers = true;
> +
>  out:
> pm_runtime_put_sync(dev->dev);
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> index dbc0689..0d1dbb7 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> @@ -33,6 +33,21 @@ struct mdp4_plane {
>  };
>  #define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)
>
> +/* MDP format helper functions */
> +static inline
> +enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
> +{
> +   bool is_tile = false;
> +
> +   if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
> +   is_tile = true;
> +
> +   if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
> +   return FRAME_TILE_YCBCR_420;
> +
> +   return FRAME_LINEAR;
> +}
> +
>  static void mdp4_plane_set_scanout(struct drm_plane *plane,
> struct drm_framebuffer *fb);
>  static int mdp4_plane_mode_set(struct drm_plane *plane,
> @@ -205,6 +220,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
> uint32_t op_mode = 0;
> uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
> uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
> +   enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);
>
> if (!(crtc && fb)) {
> DBG("%s: disabled!", mdp4_plane->name);
> @@ -304,6 +320,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
> 
> MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count - 1) |
> MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type) 
> |
> 
> MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample) |
> +   MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
> COND(format->unpack_tight, 
> MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));
>
> mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
> @@ -324,6 +341,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
> mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
> mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);
>
> +   if (frame_type != FRAME_LINEAR)
> +   mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
> +   MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
> +   MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
> +
> return 0;
>  }
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0773582..2f295cd 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ 

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

[Rob Clark]

Using fb modifier flag, support NV12MT format in MDP4.

v2:
- rework the modifier's description [Daniel Vetter's comment]
- drop .set_mode_config() callback [Rob Clark's comment]
v3:
- change VENDOR's name and restrict usage to NV12 [pointed by Daniel]

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c| 14 ++
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
 include/uapi/drm/drm_fourcc.h | 15 +++
 4 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3007b44..ed5d3f9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3304,6 +3304,20 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
  r->modifier[i], i);
return -EINVAL;
}
+
+   /* modifier specific checks: */
+   switch (r->modifier[i]) {
+   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
+   if (r->pixel_format != DRM_FORMAT_NV12 ||
+   width % 128 || height % 32) {
+   DRM_DEBUG_KMS("bad modifier data for plane 
%d\n", i);
+   return -EINVAL;
+   }
+   break;
+
+   default:
+   break;
+   }
}

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

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

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

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

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

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

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

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0773582..2f295cd 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -207,4 +207,19 @@
  */
 #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)

+/*
+ * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
+ *
+ * Macroblocks are laid in a Z-shape, and each pixel data is following the
+ * standard NV12 style.
+ * As for NV12, an image is the result of two frame buffers: one for Y,
+ * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer).
+ * Alignment requirements are (for each buffer):
+ 

[PATCH] drm/msm/mdp5: fix incorrect parameter for msm_framebuffer_iova()

[Stephane Viau]

The index of ->planes[] array (3rd parameter) cannot be equal to MAX_PLANE.
This looks like a typo that is now fixed.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 18a3d20..57b8f56 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -273,7 +273,7 @@ static void set_scanout_locked(struct drm_plane *plane,
mdp5_write(mdp5_kms, REG_MDP5_PIPE_SRC2_ADDR(pipe),
msm_framebuffer_iova(fb, mdp5_kms->id, 2));
mdp5_write(mdp5_kms, REG_MDP5_PIPE_SRC3_ADDR(pipe),
-   msm_framebuffer_iova(fb, mdp5_kms->id, 4));
+   msm_framebuffer_iova(fb, mdp5_kms->id, 3));

plane->fb = fb;
 }
-- 
Qualcomm Innovation Center, Inc.

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

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

[Archit Taneja]

On 05/19/2015 09:00 PM, Daniel Vetter wrote:
> On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
>> On 05/19/2015 03:04 PM, Daniel Vetter wrote:
>>> On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
 +void drm_bridge_post_disable(struct drm_bridge *bridge)
 +{
 +  if (!bridge)
 +  return;
 +
 +  drm_bridge_post_disable(bridge->next);
 +
 +  bridge->funcs->post_disable(bridge);
>>>
>>> For symmetry I'd call the post_disable hook for the next brigde _after_
>>> this one. Otherwise we break abstraction. E.g. with 1 bridge we'd have
>>>
>>> bridgeA_disable();
>>> encoder_disable();
>>> bridgeA_post_disable();
>>>
>>> But if on some other part bridge A is connected to bridge B (i.e. we
>>> replace the encoder with a combo of other_encoder+bridgeA) with your code
>>> the post_disable is suddenly interleaved with the preceeding stages in the
>>> pipeline:
>>>
>>>
>>> bridgeA_disable();
>>> bridgeB_disable();
>>> other_encoder_disable();
>>> bridgeA_post_disable();
>>> bridgeB_post_disable();
>>>
>>> Which means from the pov of bridgeA there's a difference between whether
>>> it's connected to "encoder" or "other_encoder+bridgeB". But if we reorder
>>> the post_disable sequence like I suggest we'll get:
>>>
>>> bridgeA_disable();
>>> bridgeB_disable();
>>> other_encoder_disable();
>>> bridgeB_post_disable();
>>> bridgeA_post_disable();
>>>
>>> Which means that "encoder" and "other_encoder+bridgeB" look the same for
>>> bridgeA. To avoid confusion the two pipelines in hw are:
>>>
>>> encoder ---> bridgeA
>>>
>>> other_encoder ---> bridgeB ---> bridgeA
>>
>> I agree with this, thanks for the explanation. Although, I'm not sure about
>> the pre_enable part below.
>>
>> 
>>
 +void drm_bridge_pre_enable(struct drm_bridge *bridge)
 +{
 +  if (!bridge)
 +  return;
 +
 +  bridge->funcs->pre_enable(bridge);
 +
 +  drm_bridge_pre_enable(bridge->next);
>>>
>>> Same as with post_disable, pre_enable for bridge->next should be called
>>> _before_ the pre_enable for this bridge.
>>
>>
>> The order of nesting suggested by you gives the sequence:
>>
>> bridgeA_pre_enable();
>> bridgeB_pre_enable();
>> other_encoder_enable();
>> bridgeB_enable();
>> bridgeA_enable();
>>
>> This won't work if the bridge A relies on bridge B to be enabled first. This
>> happens in the encoder path I'm working on:
>>
>> msm mdp5 encoder -> dsi bridge -> adv7511 dsi to hdmi bridge chip
>>
>>
>> The adv chip relies on dsi's clock for it to function. If dsi's pre_enable()
>> isn't called first, then adv's pre_enable would fail.
>
> If you need the clock, then imo that's code which should be in the enable
> hook, and not in the pre-enable hook. At least thus far the rules have
> roughly been:
> - pre_enable: anything that needs to be done _before_ clock+timings are
>enabled by the source for this bridge.
> - enable: anything that needs clock+timings to be on from the source for
>this bridge.

Okay. I think I got the rules wrong. I assumed that pre_enable() should 
do the heavy enabling. This happened because I was looking at the 
bridges(dsi/hdmi/edp) in msm as reference. Those were actually a special 
case, where the bridge feeds back the pixel clock to the mdp encoder. 
That's why everything was stuffed within pre_enable. They can afford to 
not comply to the rules since they are tightly coupled with the msm driver.

>
> Similar for the disable side:
> - disable still has clocks+timing on.
> - post_disable should be called after clocks are off.
>
> In i915 we once had a callback in between clock enabling and timing
> enabling, but we've removed that again after some restructuring. Maybe we
> need such a hook bridges? But that also means we need to split up
> encoder/crtc callbacks, and that will get nasty real fast.

Yeah, let's stay away from that!

>
>> We could modify the call order in drm_bridge_enable() instead to achieve:
>>
>> bridgeB_pre_enable();
>> bridgeA_pre_enable();
>> other_encoder_enable();
>> bridgeA_enable();
>> bridgeB_enable();
>>
>> This fixes the sequence for pre_enable() calls, but assumes that the
>> configurations in the enable() don't need to follow a specific sequence to
>> ensure proper behavior.
>>
>> pre_enable() should ideally represent things to be done before we enable the
>> next encoder in the chain. So the sequence right above seems to be better.
>
> Nah, that's even more backwards imo. From bridgeA's pov it really should
> make no difference at all whether the input is directly from an encoder or
> whether it's "other_encoder+bridgeB". If we leak this detail down the
> bridge chain, then the abstraction is leaky and bridge drivers will be
> impossible to be reused.

Right. That makes sense. I came up with that to under the assumption 
that the bridge's source should be ready with clocks and timings, which 
was wrong. I'll stick to the order you mentioned.

Thanks,
Archit

-- 
Qualcomm Innovation Center, 

[PATCH] drm/plane-helper: Adapt cursor hack to transitional helpers

[Daniel Vetter]

In

commit f02ad907cd9e7fe3a6405d2d005840912f1ed258
Author: Daniel Vetter 
Date:   Thu Jan 22 16:36:23 2015 +0100

drm/atomic-helpers: Recover full cursor plane behaviour

we've added a hack to atomic helpers to never to vblank waits for
cursor updates through the legacy apis since that's what X expects.
Unfortunately we've (again) forgotten to adjust the transitional
helpers. Do this now.

This fixes regressions for drivers only partially converted over to
atomic (like i915).

Reported-by: Pekka Paalanen 
Cc: Pekka Paalanen 
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 40c1db9ad7c3..2f0ed11024eb 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -465,6 +465,9 @@ int drm_plane_helper_commit(struct drm_plane *plane,
if (!crtc[i])
continue;

+   if (crtc[i]->cursor == plane)
+   continue;
+
/* There's no other way to figure out whether the crtc is 
running. */
ret = drm_crtc_vblank_get(crtc[i]);
if (ret == 0) {
-- 
2.1.4

[PATCH 03/12] drm/amdkfd: Use DECLARE_BITMAP

[Oded Gabbay]

On Wed, May 20, 2015 at 4:37 AM, Joe Perches  wrote:
> Use the generic mechanism to declare a bitmap instead of unsigned long.
>
> It seems that "struct kfd_process.allocated_queue_bitmap" is unused.
> Maybe it could be deleted instead.
>
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index f21fcce..aba3e5d 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@ -150,8 +150,7 @@ struct kfd_dev {
>
> const struct kfd2kgd_calls *kfd2kgd;
> struct mutex doorbell_mutex;
> -   unsigned long doorbell_available_index[DIV_ROUND_UP(
> -   KFD_MAX_NUM_OF_QUEUES_PER_PROCESS, BITS_PER_LONG)];
> +   DECLARE_BITMAP(doorbell_available_index, 
> KFD_MAX_NUM_OF_QUEUES_PER_PROCESS);
>
> void *gtt_mem;
> uint64_t gtt_start_gpu_addr;
> @@ -473,7 +472,7 @@ struct kfd_process {
> /* Size is queue_array_size, up to MAX_PROCESS_QUEUES. */
> struct kfd_queue **queues;
>
> -   unsigned long 
> allocated_queue_bitmap[DIV_ROUND_UP(KFD_MAX_NUM_OF_QUEUES_PER_PROCESS, 
> BITS_PER_LONG)];
> +   DECLARE_BITMAP(allocated_queue_bitmap, 
> KFD_MAX_NUM_OF_QUEUES_PER_PROCESS);
>
> /*Is the user space process 32 bit?*/
> bool is_32bit_user_mode;
> --
> 2.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Thanks!
I indeed deleted the allocated_queue_bitmap and squashed it into your
patch. It was a residue from a very early version.
Applied to my -next branch.

Oded

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

["Stéphane Viau"]

Hi Rob,

> Using fb modifier flag, support NV12MT format in MDP4.
>
> v2:
> - rework the modifier's description [Daniel Vetter's comment]
> - drop .set_mode_config() callback [Rob Clark's comment]
> v3:
> - change VENDOR's name and restrict usage to NV12 [pointed by Daniel]
>
> Signed-off-by: Rob Clark 

Looks good to me.
Thank you for submitting this patch.

Stephane.

> ---
>  drivers/gpu/drm/drm_crtc.c| 14 ++
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
>  include/uapi/drm/drm_fourcc.h | 15 +++
>  4 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3007b44..ed5d3f9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3304,6 +3304,20 @@ static int framebuffer_check(const struct
> drm_mode_fb_cmd2 *r)
> r->modifier[i], i);
>   return -EINVAL;
>   }
> +
> + /* modifier specific checks: */
> + switch (r->modifier[i]) {
> + case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
> + if (r->pixel_format != DRM_FORMAT_NV12 ||
> + width % 128 || height % 32) {
> + DRM_DEBUG_KMS("bad modifier data for plane 
> %d\n", i);
> + return -EINVAL;
> + }
> + break;
> +
> + default:
> + break;
> + }
>   }
>
>   return 0;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index d847b94..88a75cb 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -119,6 +119,8 @@ static int mdp4_hw_init(struct msm_kms *kms)
>   if (mdp4_kms->rev > 1)
>   mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
>
> + dev->mode_config.allow_fb_modifiers = true;
> +
>  out:
>   pm_runtime_put_sync(dev->dev);
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> index dbc0689..0d1dbb7 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> @@ -33,6 +33,21 @@ struct mdp4_plane {
>  };
>  #define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)
>
> +/* MDP format helper functions */
> +static inline
> +enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
> +{
> + bool is_tile = false;
> +
> + if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
> + is_tile = true;
> +
> + if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
> + return FRAME_TILE_YCBCR_420;
> +
> + return FRAME_LINEAR;
> +}
> +
>  static void mdp4_plane_set_scanout(struct drm_plane *plane,
>   struct drm_framebuffer *fb);
>  static int mdp4_plane_mode_set(struct drm_plane *plane,
> @@ -205,6 +220,7 @@ static int mdp4_plane_mode_set(struct drm_plane
> *plane,
>   uint32_t op_mode = 0;
>   uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
>   uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
> + enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);
>
>   if (!(crtc && fb)) {
>   DBG("%s: disabled!", mdp4_plane->name);
> @@ -304,6 +320,7 @@ static int mdp4_plane_mode_set(struct drm_plane
> *plane,
>   MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count 
> - 1) |
>   MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type) |
>   MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample) 
> |
> + MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
>   COND(format->unpack_tight, 
> MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));
>
>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
> @@ -324,6 +341,11 @@ static int mdp4_plane_mode_set(struct drm_plane
> *plane,
>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
>   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);
>
> + if (frame_type != FRAME_LINEAR)
> + mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
> + MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
> + MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
> +
>   return 0;
>  }
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0773582..2f295cd 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -207,4 +207,19 @@
>   */
>  #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
>
> +/*
> + * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> + *
> + * Macroblocks are laid in a Z-shape, and each pixel data is following
> 

Experiencing FIFO underruns on Intel Skylake platform

[Rainer Koenig]

Am 19.05.2015 um 13:41 schrieb Jani Nikula:
> 
> +intel-gfx

> For brand new platforms you should be running drm-intel-nightly branch
> from http://cgit.freedesktop.org/drm-intel.

Tested now, drm-intel-nightly solves the problem.

Thanks a lot
Rainer
-- 
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Clients
Dept. PDG WPS R SW OSE

Fujitsu Technology Solutions
Bürgermeister-Ullrich-Str. 100
86199 Augsburg
Germany

Telephone: +49-821-804-3321
Telefax:   +49-821-804-2131
Mail:  mailto:Rainer.Koenig at ts.fujitsu.com

Internet ts.fujtsu.com
Company Details  ts.fujitsu.com/imprint.html

[PATCH] drm: remove unused function 'drm_property_unreference_blob_locked'

[Jani Nikula]

On Wed, 20 May 2015, Arnd Bergmann  wrote:
> This function was added recently but never used, and causes
> a compile warning:
>
> drivers/gpu/drm/drm_crtc.c:4324:13: warning: 
> 'drm_property_unreference_blob_locked' defined but not used 
> [-Wunused-function]
>
> Removing that function avoids the warning. It can simply be put
> back in case it is needed in the future.

http://mid.gmane.org/CAPj87rMPtafeYNzgXoP+fx0dAqhwaD7kdnJgqb_vdbPtiOrXPg at 
mail.gmail.com

>
> Signed-off-by: Arnd Bergmann 
> Fixes: 6bcacf51d05 ("drm: Add reference counting to blob properties")
> ---
> The broken patch is currently in
> git://anongit.freedesktop.org/drm-intel#topic/drm-misc
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4059f065c854..6e60f71bbf46 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4313,25 +4313,6 @@ void drm_property_unreference_blob(struct 
> drm_property_blob *blob)
>  EXPORT_SYMBOL(drm_property_unreference_blob);
>  
>  /**
> - * drm_property_unreference_blob_locked - Unreference a blob property with 
> blob_lock held
> - *
> - * Drop a reference on a blob property. May free the object. This must be
> - * called with blob_lock held.
> - *
> - * @param dev  Device the blob was created on
> - * @param blob Pointer to blob property
> - */
> -static void drm_property_unreference_blob_locked(struct drm_property_blob 
> *blob)
> -{
> - if (!blob)
> - return;
> -
> - DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id, 
> atomic_read(>refcount.refcount));
> -
> - kref_put(>refcount, drm_property_free_blob);
> -}
> -
> -/**
>   * drm_property_reference_blob - Take a reference on an existing property
>   *
>   * Take a new reference on an existing blob property.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm: drop drm_property_unreference_blob_locked()

[Jani Nikula]

On Tue, 19 May 2015, Sergey Senozhatsky  wrote:
> drm_property_unreference_blob_locked() is static and unused,
> drop it.

http://mid.gmane.org/CAPj87rMPtafeYNzgXoP+fx0dAqhwaD7kdnJgqb_vdbPtiOrXPg at 
mail.gmail.com

>
> Signed-off-by: Sergey Senozhatsky 
> ---
>  drivers/gpu/drm/drm_crtc.c | 19 ---
>  1 file changed, 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4059f06..6e60f71 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4313,25 +4313,6 @@ void drm_property_unreference_blob(struct 
> drm_property_blob *blob)
>  EXPORT_SYMBOL(drm_property_unreference_blob);
>  
>  /**
> - * drm_property_unreference_blob_locked - Unreference a blob property with 
> blob_lock held
> - *
> - * Drop a reference on a blob property. May free the object. This must be
> - * called with blob_lock held.
> - *
> - * @param dev  Device the blob was created on
> - * @param blob Pointer to blob property
> - */
> -static void drm_property_unreference_blob_locked(struct drm_property_blob 
> *blob)
> -{
> - if (!blob)
> - return;
> -
> - DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id, 
> atomic_read(>refcount.refcount));
> -
> - kref_put(>refcount, drm_property_free_blob);
> -}
> -
> -/**
>   * drm_property_reference_blob - Take a reference on an existing property
>   *
>   * Take a new reference on an existing blob property.
> -- 
> 2.4.1.168.g1ea28e1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] nouveau: add coherent BO attribute

[Martin Peres]

On 20/05/15 08:11, Alexandre Courbot wrote:
> On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
>  wrote:
>> Op 15-05-15 om 09:11 schreef Alexandre Courbot:
>>> Re-pinging Marteen on an email address that still exists :P
>>>
>>> On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot  
>>> wrote:
 On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot >>> nvidia.com> wrote:
> On 03/14/2015 04:33 AM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 13-03-15 om 07:27 schreef Alexandre Courbot:
>>> Add a flag allowing Nouveau to specify that an object should be coherent
>>> at allocation time. This is required for some class of objects like
>>> fences which are randomly-accessed by both the CPU and GPU. This flag
>>> instructs the kernel driver to make sure the object remains coherent
>>> even on architectures for which coherency is not guaranteed by the bus.
>>>
>>> Signed-off-by: Alexandre Courbot 
>> I don't see a problem with this patch, but similar patches to intel to
>> libdrm have been shot down when the changes weren't in an official kernel
>> yet, so I think this should wait until the change is at least in 
>> drm-next.
>> ;-)
> Sounds good. I will ping you again once the kernel change reaches -next.
 Hi Marteen,

 The kernel change required for this patch is now in -next. Do you
 think we can merge it now?
>> I think it would be ok to merge now.
> Great - who could do this? :P

I could do it. Please provide me with the patch with the necessary R-b 
and I can push it to our libdrm (and/or mesa).

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

[Daniel Vetter]

On Wed, May 20, 2015 at 12:43:40PM +0530, Archit Taneja wrote:
> Where do you think drm_bridge documentation fits? I was considering putting
> it under 'KMS initialization and setup', while pointing out that it isn't
> exactly a drm_mode_object entity like crtcs or encoders etc.

Since drm_bridge is not exposed to userspace it's not part of core drm and
imo should be a helper library - it's only used by drivers internally to
help them implement modesetting. New chapter under "Mode Setting Helper
Functions" sounds best to me.

Btw drm_bridge being a core part of drm is another thing we probably
should fix up eventually. I looked into doing that a while ago, but it
wasn't quite that simple. And I don't have a good arm build-test setup, so
hard to make sure I've caught all drivers and made sure they depend upon
DRM_KMS_HELPER properly.

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

[PATCH] drm/nouveau/platform: add IOMMU dependency

[Alexandre Courbot]

On 05/19/2015 09:53 PM, Arnd Bergmann wrote:
> The recently added iommu code in the nouveau driver fails to build
> when the IOMMU support is disabled:
>
> drivers/gpu/drm/nouveau/nouveau_platform.c: In function 
> 'nouveau_platform_probe_iommu':
> drivers/gpu/drm/nouveau/nouveau_platform.c:113:41: error: 'const struct 
> iommu_ops' has no mem
>
> To avoid the build error, this now adds an explicit dependency on the
> IOMMU implementation.

I have a local patch to nouveau_platform.c that only calls the IOMMU 
functions if CONFIG_IOMMU is set. Wouldn't this be more suitable as 
IOMMU support is only used by Tegra and thus not beneficial for desktop 
GPUs?

[PATCH v2] drm/msm: use devm_gpiod_get_optional for optional reset gpio

[Uwe Kleine-König]

Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.

Also there is a variant to find optional gpios that returns NULL if
there is no gpio instead of -ENOENT.

Make use of both features to simplify the driver.

This makes error checking more strict because errors like -ENOSYS ("no
gpio support compiled in") or -EPROBE_DEFER ("gpio not ready yet") are
handled correctly now.

Furthermore this is one caller less that stops us making the flags
argument to gpiod_get*() mandatory.

Reviewed-by: Linus Walleij 
Signed-off-by: Uwe Kleine-König 
---

Notes:
Changes since (implicit) v1 sent with
Message-Id: 1432021249-24183-1-git-send-email-u.kleine-koenig at 
pengutronix.de:

 - remove now unused variable ret (thanks to the kbuild test robot)
 - add Reviewed-by for Linus W. (I hope that's ok in spite of the above 
change)
 - drop Fixes: line

 drivers/gpu/drm/msm/dsi/dsi_host.c | 29 ++---
 1 file changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 956b22492c9a..bf0d1727ab77 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1351,36 +1351,19 @@ static irqreturn_t dsi_host_irq(int irq, void *ptr)
 static int dsi_host_init_panel_gpios(struct msm_dsi_host *msm_host,
struct device *panel_device)
 {
-   int ret;
-
-   msm_host->disp_en_gpio = devm_gpiod_get(panel_device,
-   "disp-enable");
+   msm_host->disp_en_gpio = devm_gpiod_get_optional(panel_device,
+"disp-enable",
+GPIOD_OUT_LOW);
if (IS_ERR(msm_host->disp_en_gpio)) {
DBG("cannot get disp-enable-gpios %ld",
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;
-   }
+   return PTR_ERR(msm_host->disp_en_gpio);
}

-   msm_host->te_gpio = devm_gpiod_get(panel_device, "disp-te");
+   msm_host->te_gpio = devm_gpiod_get(panel_device, "disp-te", GPIOD_IN);
if (IS_ERR(msm_host->te_gpio)) {
DBG("cannot get disp-te-gpios %ld", PTR_ERR(msm_host->te_gpio));
-   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;
-   }
+   return PTR_ERR(msm_host->te_gpio);
}

return 0;
-- 
2.1.4

[PATCH] ARM: dts: exynos4412-trats2: set display clock correctly

[Krzysztof Kozlowski]

2015-02-07 19:49 GMT+09:00 Inki Dae :
> This patch sets display clock correctly.
>
> If Display clock isn't set correctly then you would find below messages
> and Display controller doesn't work correctly since a patch[1]
>
>exynos-drm: No connectors reported connected with modes
>[drm] Cannot find any crtc or sizes - going 1024x768
>
> [1] commit abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")

Reviewed-by: Krzysztof Kozlowski 
Tested-by: Krzysztof Kozlowski 

Tested on Trats2 board.

Dear Kukjin,

Could you pull it to current fixes branch (this RC cycle)? The patch
fixes display on Trats2 board. Without it (since abc0b1447d49) it
won't be properly set up and device boots with blank screen and
mentioned error message in logs.

I think this actually is a candidate for stable backporting (4.0+)
because it fixes important functionality of device:

Fixes: abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
Cc: 

Best regards,
Krzysztof

[PATCH] drm/nouveau/platform: fix compilation if !CONFIG_IOMMU

[Arnd Bergmann]

On Wednesday 20 May 2015 15:10:24 Alexandre Courbot wrote:
> The lack of IOMMU API support can make nouveau_platform_probe_iommu()
> fail to compile because struct iommu_ops is then empty. Fix this by
> skipping IOMMU probe in that case - lack of IOMMU on platform devices
> is sub-optimal, but is not an error.
> 
> Signed-off-by: Alexandre Courbot 
> ---
> This is an alternative to https://lkml.org/lkml/2015/5/19/484. Most users
> of Nouveau do not care about IOMMU support, so we should not impose that
> option on them.
> 

Yes, good idea.

Acked-by: Arnd Bergmann 

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

[Daniel Vetter]

On Wed, May 20, 2015 at 10:49:38AM +0530, Archit Taneja wrote:
> On 05/19/2015 09:00 PM, Daniel Vetter wrote:
> >On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
> >>On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> >>>On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
> +void drm_bridge_post_disable(struct drm_bridge *bridge)
> +{
> + if (!bridge)
> + return;
> +
> + drm_bridge_post_disable(bridge->next);
> +
> + bridge->funcs->post_disable(bridge);
> >>>
> >>>For symmetry I'd call the post_disable hook for the next brigde _after_
> >>>this one. Otherwise we break abstraction. E.g. with 1 bridge we'd have
> >>>
> >>>bridgeA_disable();
> >>>encoder_disable();
> >>>bridgeA_post_disable();
> >>>
> >>>But if on some other part bridge A is connected to bridge B (i.e. we
> >>>replace the encoder with a combo of other_encoder+bridgeA) with your code
> >>>the post_disable is suddenly interleaved with the preceeding stages in the
> >>>pipeline:
> >>>
> >>>
> >>>bridgeA_disable();
> >>>bridgeB_disable();
> >>>other_encoder_disable();
> >>>bridgeA_post_disable();
> >>>bridgeB_post_disable();
> >>>
> >>>Which means from the pov of bridgeA there's a difference between whether
> >>>it's connected to "encoder" or "other_encoder+bridgeB". But if we reorder
> >>>the post_disable sequence like I suggest we'll get:
> >>>
> >>>bridgeA_disable();
> >>>bridgeB_disable();
> >>>other_encoder_disable();
> >>>bridgeB_post_disable();
> >>>bridgeA_post_disable();
> >>>
> >>>Which means that "encoder" and "other_encoder+bridgeB" look the same for
> >>>bridgeA. To avoid confusion the two pipelines in hw are:
> >>>
> >>>encoder ---> bridgeA
> >>>
> >>>other_encoder ---> bridgeB ---> bridgeA
> >>
> >>I agree with this, thanks for the explanation. Although, I'm not sure about
> >>the pre_enable part below.
> >>
> >>
> >>
> +void drm_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + if (!bridge)
> + return;
> +
> + bridge->funcs->pre_enable(bridge);
> +
> + drm_bridge_pre_enable(bridge->next);
> >>>
> >>>Same as with post_disable, pre_enable for bridge->next should be called
> >>>_before_ the pre_enable for this bridge.
> >>
> >>
> >>The order of nesting suggested by you gives the sequence:
> >>
> >>bridgeA_pre_enable();
> >>bridgeB_pre_enable();
> >>other_encoder_enable();
> >>bridgeB_enable();
> >>bridgeA_enable();
> >>
> >>This won't work if the bridge A relies on bridge B to be enabled first. This
> >>happens in the encoder path I'm working on:
> >>
> >>msm mdp5 encoder -> dsi bridge -> adv7511 dsi to hdmi bridge chip
> >>
> >>
> >>The adv chip relies on dsi's clock for it to function. If dsi's pre_enable()
> >>isn't called first, then adv's pre_enable would fail.
> >
> >If you need the clock, then imo that's code which should be in the enable
> >hook, and not in the pre-enable hook. At least thus far the rules have
> >roughly been:
> >- pre_enable: anything that needs to be done _before_ clock+timings are
> >   enabled by the source for this bridge.
> >- enable: anything that needs clock+timings to be on from the source for
> >   this bridge.
> 
> Okay. I think I got the rules wrong. I assumed that pre_enable() should do
> the heavy enabling. This happened because I was looking at the
> bridges(dsi/hdmi/edp) in msm as reference. Those were actually a special
> case, where the bridge feeds back the pixel clock to the mdp encoder. That's
> why everything was stuffed within pre_enable. They can afford to not comply
> to the rules since they are tightly coupled with the msm driver.
> 
> >
> >Similar for the disable side:
> >- disable still has clocks+timing on.
> >- post_disable should be called after clocks are off.
> >
> >In i915 we once had a callback in between clock enabling and timing
> >enabling, but we've removed that again after some restructuring. Maybe we
> >need such a hook bridges? But that also means we need to split up
> >encoder/crtc callbacks, and that will get nasty real fast.
> 
> Yeah, let's stay away from that!
> 
> >
> >>We could modify the call order in drm_bridge_enable() instead to achieve:
> >>
> >>bridgeB_pre_enable();
> >>bridgeA_pre_enable();
> >>other_encoder_enable();
> >>bridgeA_enable();
> >>bridgeB_enable();
> >>
> >>This fixes the sequence for pre_enable() calls, but assumes that the
> >>configurations in the enable() don't need to follow a specific sequence to
> >>ensure proper behavior.
> >>
> >>pre_enable() should ideally represent things to be done before we enable the
> >>next encoder in the chain. So the sequence right above seems to be better.
> >
> >Nah, that's even more backwards imo. From bridgeA's pov it really should
> >make no difference at all whether the input is directly from an encoder or
> >whether it's "other_encoder+bridgeB". If we leak this detail down the
> >bridge chain, then the abstraction is leaky and bridge drivers will be
> >impossible to be reused.
> 
> Right. That 

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

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

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

--- Comment #5 from Michel Dänzer  ---
Can you try isolating the LLVM change introducing it with git bisect? Note that
this might require some tweaking because current Mesa might fail to build
against some development snapshots of LLVM.

-- 
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/20150520/b84357e0/attachment.html>

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

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

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #115901|text/plain  |application/gzip
  mime type||

-- 
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/20150520/841c6e1c/attachment.html>

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

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

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #115900|text/plain  |application/gzip
  mime type||

-- 
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/20150520/e5478e25/attachment.html>

[Bug 90263] GPU card fans run full speed at all times

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

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

--- Comment #11 from Todd  ---
I was expecting this problem to be solved through the miracle of "dynamic power
management support" brought down from the mountain of Linux 4.

I had assumed that the GPU was running at full power all the time under the
Linux Radeon driver, hence the loud fans. When booted to Windows 7, the card is
quiet.

Is fan speed control a different issue? I'm losing track of what this issue is
a symptom of and where to correctly report the bug.

-- 
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/20150520/23cda902/attachment.html>

4.1-rc4 display-port on radeon not working

[Malte Schröder]

Hi,
with 4.1-rc display-port on my Tahiti XT stopped working. I used the
firmware from http://people.freedesktop.org/~agd5f/radeon_ucode/ as of
today.
Note: the display is an Asus PB278, it used to have problems with
display port negotiation, but those disappeared like a year ago.

% grep radeon /tmp/dmesg.txt
[2.520294] [drm] radeon kernel modesetting enabled.
[2.520328] fb: switching to radeondrmfb from simple
[2.520727] radeon :01:00.0: VRAM: 3072M 0x -
0xBFFF (3072M used)
[2.520729] radeon :01:00.0: GTT: 1024M 0xC000 -
0x
[2.520830] [drm] radeon: 3072M of VRAM memory ready
[2.520831] [drm] radeon: 1024M of GTT memory ready.
[2.534959] [drm] radeon: dpm initialized
[2.542742] radeon :01:00.0: WB enabled
[2.542745] radeon :01:00.0: fence driver on ring 0 use gpu addr
0xcc00 and cpu addr 0x880803febc00
[2.542746] radeon :01:00.0: fence driver on ring 1 use gpu addr
0xcc04 and cpu addr 0x880803febc04
[2.542747] radeon :01:00.0: fence driver on ring 2 use gpu addr
0xcc08 and cpu addr 0x880803febc08
[2.542748] radeon :01:00.0: fence driver on ring 3 use gpu addr
0xcc0c and cpu addr 0x880803febc0c
[2.542749] radeon :01:00.0: fence driver on ring 4 use gpu addr
0xcc10 and cpu addr 0x880803febc10
[2.543159] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x00075a18 and cpu addr 0xc9435a18
[2.543162] radeon :01:00.0: radeon: MSI limited to 32-bit
[2.543178] radeon :01:00.0: radeon: using MSI.
[2.543192] [drm] radeon: irq initialized.
[3.567418] fbcon: radeondrmfb (fb0) is primary device
[3.573492] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport
link status failed
[3.573504] [drm:radeon_dp_link_train [radeon]] *ERROR* clock
recovery failed
[3.575533] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[3.575534] radeon :01:00.0: registered panic notifier
[3.582468] [drm] Initialized radeon 2.42.0 20080528 for :01:00.0
on minor 0

lspci -vvv:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] (prog-if 00 [VGA
controller])
Subsystem: XFX Pine Group Inc. Double D HD 7970
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1,
Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-,
LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-,
LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance-
SpeedDis-
 Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete+, EqualizationPhase1+
 EqualizationPhase2+, EqualizationPhase3+,
LinkEqualizationRequest-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: feeff00c  Data: 41c2
Capabilities: [100 v1] Vendor Specific Information: ID=0001
Rev=1 Len=010 
Capabilities: [150 v2] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- 

[PATCH] Add device enumeration interface (v3)

[Jammy Zhou]

From: frank 

v3: switch to udev/sysfs for the enumeration

Signed-off-by: Frank Min 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
---
 Makefile.am |   7 +++--
 xf86drm.c   | 103 
 xf86drm.h   |  19 +++
 3 files changed, 127 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 13df80c..ffd334a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -95,12 +95,15 @@ SUBDIRS = \
 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
 libdrm_la_LDFLAGS = -version-number 2:4:0 -no-undefined
-libdrm_la_LIBADD = @CLOCK_LIB@
+libdrm_la_LIBADD = \
+   @CLOCK_LIB@ \
+   @LIBUDEV_LIBS@

 libdrm_la_CPPFLAGS = -I$(top_srcdir)/include/drm
 AM_CFLAGS = \
$(WARN_CFLAGS) \
-   $(VALGRIND_CFLAGS)
+   $(VALGRIND_CFLAGS) \
+   $(LIBUDEV_CFLAGS)

 libdrm_la_SOURCES = $(LIBDRM_FILES)

diff --git a/xf86drm.c b/xf86drm.c
index f7c45f8..d2704de 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -63,6 +63,7 @@

 #include "xf86drm.h"
 #include "libdrm_macros.h"
+#include "libudev.h"

 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || 
defined(__DragonFly__)
 #define DRM_MAJOR 145
@@ -2817,3 +2818,105 @@ char *drmGetRenderDeviceNameFromFd(int fd)
 {
return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
 }
+
+/**
+* Enumerate the GPU devices on the system
+*
+* \param devs device array set to return the device information
+* (if NULL, the number of device is returned)
+* \param vendor the vendor ID for GPU devices to list
+* (optional, if not specified, all GPU devices are returned)
+*
+* \return the number of GPU devices
+*/
+int drmGetPciDevices(drmPciDevicePtr devSet, uint16_t vendorId)
+{
+   struct udev *udev = NULL;
+   struct udev_enumerate *udev_enumerate;
+   struct udev_list_entry *list_entry;
+   struct udev_device *device;
+   int drmDevCount = 0;
+   int vendor = 0;
+   int devid = 0;
+   int devclass = 0;
+   int subvendor = 0;
+   int subdevid = 0;
+   int revid = 0xff;
+   int domain = 0;
+   int bus = 0;
+   int dev = 0;
+   int func = 0;
+   char config[64] = {0};
+   char node[128] = {'\0'};
+   char slot[] = ":00:00.0";
+   char *info = NULL;
+   int minor = 0xff;
+   int fd = 0;
+   int ret = 0;
+
+   udev = udev_new();
+   if (udev == NULL) {
+   fprintf(stderr, "no context\n");
+   return -EINVAL;
+   }
+   udev_enumerate = udev_enumerate_new(udev);
+   if (udev_enumerate == NULL)
+   return -EINVAL;
+   udev_enumerate_add_match_subsystem(udev_enumerate, "drm");
+   udev_enumerate_add_match_property(udev_enumerate, "DEVTYPE", 
"drm_minor");
+
+   udev_enumerate_scan_devices(udev_enumerate);
+
+   udev_list_entry_foreach(list_entry, 
udev_enumerate_get_list_entry(udev_enumerate)) {
+   device = 
udev_device_new_from_syspath(udev_enumerate_get_udev(udev_enumerate),
+ 
udev_list_entry_get_name(list_entry));
+   if (device != NULL) {
+   info = udev_device_get_property_value(device, "MINOR");
+   if (!strcmp(info, "0")) {
+   strcpy(node, udev_device_get_syspath(device));
+   info = strstr(node, "/drm");
+   strncpy(slot, info - strlen(slot), strlen(slot));
+   if (sscanf(slot, "%4x:%2x:%2x.%1x", , , 
, ) != 4) {
+   domain = 0;
+   bus = 0;
+   dev = 0;
+   func = 0;
+   }
+   strcpy(node + strlen(node), "/device/config");
+
+   fd = open(node, O_RDONLY);
+   if (fd >= 0) {
+   ret = read(fd, config, 64);
+   if (ret == 64) {
+   vendor = config[0] + (config[1] << 8);
+   devid = config[2] + (config[3] << 8);
+   revid = config[8];
+   devclass = config[9] + (config[10] << 
8) + (config[11] << 16);
+   subdevid = config[44] + (config[45] << 
8);
+   }
+   close(fd);
+   }
+
+   if((vendorId == 0) || (vendorId == vendor)) {
+   if(devSet != NULL) {
+   devSet[drmDevCount].domain = domain;
+   devSet[drmDevCount].bus = bus;
+   devSet[drmDevCount].dev = dev;
+   devSet[drmDevCount].func = 

[GIT PULL] exynos-drm-fixes

[inki....@samsung.com]

Hi Dave,

   This pull request contains mainly some regression fixups and code cleanups.

Summary:
- Use generic function to get buffer count instead of specific one.
  In case of Exynos DRM, There was a special case which decides pixel
  format of a given buffer according to planer types, which is NV12M and NV12.
  However, NV12M doesn't exist in drm fourcc so it removes
  exynos_drm_format_num_buffers() specific to Exynos DRM and use a generic 
function,
  drm_format_num_planes() instead.
- Allow mixer driver to support NV21 format for Video processor.
  This format was already supported but we just missed DRM_FORMAT_NV21 case
  so this patch considers the case so that Mixer driver can handle it correctly.
- Add regression fix and some code cleanups.

 Please kindly let me know if there is any problem.

 Thanks,
 Inki Dae

The following changes since commit 64d237e66d562348f04a9c04a45455c1f3201ced:

  Merge branch 'msm-fixes-4.1' of git://people.freedesktop.org/~robclark/linux 
into drm-fixes (2015-05-19 10:17:34 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to b0f155ada4c819f06aa32b4c906e7e76350c7ec1:

  drm/exynos: dp: Lower level of EDID read success message (2015-05-19 22:50:55 
+0900)


Krzysztof Kozlowski (5):
  drm/exynos: mixer: Constify platform_device_id
  drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
  drm/exynos: Constify exynos_drm_crtc_ops
  drm/exynos: Consolidate return statements in fimd_bind()
  drm/exynos: dp: Lower level of EDID read success message

Tobias Jakobi (8):
  drm/exynos: fb: use drm_format_num_planes to get buffer count
  drm/exynos: plane: honor buffer offset for dma_addr
  drm/exynos: mixer: remove buffer count handling in vp_video_buffer()
  drm/exynos: mixer: also allow NV21 for the video processor
  drm/exynos: mixer: cleanup pixelformat handling
  drm/exynos: mixer: don't dump registers under spinlock
  drm/exynos: 'win' is always unsigned
  drm/exynos: cleanup exynos_drm_plane

 drivers/gpu/drm/exynos/exynos7_drm_decon.c |4 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c|   13 +++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   10 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   10 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   20 +++-
 drivers/gpu/drm/exynos/exynos_drm_fb.c |   39 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   53 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.h   |   15 --
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  |   72 +++-
 11 files changed, 92 insertions(+), 148 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd.h

[PATCH] drm: remove unused function 'drm_property_unreference_blob_locked'

[Arnd Bergmann]

This function was added recently but never used, and causes
a compile warning:

drivers/gpu/drm/drm_crtc.c:4324:13: warning: 
'drm_property_unreference_blob_locked' defined but not used [-Wunused-function]

Removing that function avoids the warning. It can simply be put
back in case it is needed in the future.

Signed-off-by: Arnd Bergmann 
Fixes: 6bcacf51d05 ("drm: Add reference counting to blob properties")
---
The broken patch is currently in
git://anongit.freedesktop.org/drm-intel#topic/drm-misc

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4059f065c854..6e60f71bbf46 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4313,25 +4313,6 @@ void drm_property_unreference_blob(struct 
drm_property_blob *blob)
 EXPORT_SYMBOL(drm_property_unreference_blob);

 /**
- * drm_property_unreference_blob_locked - Unreference a blob property with 
blob_lock held
- *
- * Drop a reference on a blob property. May free the object. This must be
- * called with blob_lock held.
- *
- * @param dev  Device the blob was created on
- * @param blob Pointer to blob property
- */
-static void drm_property_unreference_blob_locked(struct drm_property_blob 
*blob)
-{
-   if (!blob)
-   return;
-
-   DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id, 
atomic_read(>refcount.refcount));
-
-   kref_put(>refcount, drm_property_free_blob);
-}
-
-/**
  * drm_property_reference_blob - Take a reference on an existing property
  *
  * Take a new reference on an existing blob property.