Oops (NULL pointer dereference) in radeon_fence_ref in 3.14.63

[Nicolai Hähnle]

>> no_context+0x132/0x2e0
>> Mar  5 15:04:58 lutz kernel: [ 6995.240216]  []
>> __bad_area_nosemaphore+0x115/0x210
>> Mar  5 15:04:58 lutz kernel: [ 6995.240218]  [] ?
>> __alloc_pages_nodemask+0x141/0x910
>> Mar  5 15:04:58 lutz kernel: [ 6995.240220]  []
>> bad_area_nosemaphore+0xe/0x10
>> Mar  5 15:04:58 lutz kernel: [ 6995.240222]  []
>> __do_page_fault+0x332/0x560
>> Mar  5 15:04:58 lutz kernel: [ 6995.240230]  [] ?
>> ttm_mem_global_alloc_zone.clone.1+0x12b/0x150 [ttm]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240233]  [] ?
>> ttm_mem_global_alloc_page+0x42/0x50 [ttm]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240237]  [] ?
>> alloc_pages_current+0xae/0x170
>> Mar  5 15:04:58 lutz kernel: [ 6995.240238]  []
>> do_page_fault+0xc/0x10
>> Mar  5 15:04:58 lutz kernel: [ 6995.240240]  []
>> page_fault+0x22/0x30
>> Mar  5 15:04:58 lutz kernel: [ 6995.240252]  [] ?
>> radeon_fence_ref+0x10/0x50 [radeon]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240268]  []
>> radeon_sa_bo_new+0x302/0x590 [radeon]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240270]  [] ?
>> __kmalloc+0x66/0x1d0
>> Mar  5 15:04:58 lutz kernel: [ 6995.240283]  [] ?
>> copy_from_user+0x9/0x10 [radeon]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240296]  []
>> radeon_ib_get+0x43/0xe0 [radeon]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240309]  []
>> radeon_cs_ioctl+0x201/0xac0 [radeon]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240312]  [] ?
>> idr_mark_full+0x52/0x70
>> Mar  5 15:04:58 lutz kernel: [ 6995.240320]  []
>> drm_ioctl+0x401/0x580 [drm]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240333]  [] ?
>> radeon_cs_parser_init+0x470/0x470 [radeon]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240335]  [] ?
>> __do_page_fault+0x1cc/0x560
>> Mar  5 15:04:58 lutz kernel: [ 6995.240346]  []
>> radeon_drm_ioctl+0x9/0x10 [radeon]
>> Mar  5 15:04:58 lutz kernel: [ 6995.240348]  []
>> do_vfs_ioctl+0x81/0x4d0
>> Mar  5 15:04:58 lutz kernel: [ 6995.240351]  [] ?
>> SyS_mmap_pgoff+0xd9/0x210
>> Mar  5 15:04:58 lutz kernel: [ 6995.240353]  []
>> SyS_ioctl+0x91/0xa0
>> Mar  5 15:04:58 lutz kernel: [ 6995.240355]  [] ?
>> do_page_fault+0xc/0x10
>> Mar  5 15:04:58 lutz kernel: [ 6995.240357]  []
>> system_call_fastpath+0x16/0x1b
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-guard-call-to-radeon_fence_ref-against-NU.patch
Type: text/x-patch
Size: 1447 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/ff63727a/attachment-0001.bin>

[PATCH] drm/i2c: tda998x: Choose between atomic or non atomic dpms helper

[Jyri Sarha]

Hi,
Based on discussion around this patch:

https://lists.freedesktop.org/archives/dri-devel/2016-February/100685.html

I think the patch below should get into queued for v4.5 fixes as the 
Beaglebone-Black display is currently broken in linux-master and 
probably Armada is broken too. What should I do to get it there?

Best regards,
Jyri

On 01/16/16 22:17, Jyri Sarha wrote:
> Choose between atomic or non atomic connector dpms helper. If tda998x
> is connected to a drm driver that does not support atomic modeset
> calling drm_atomic_helper_connector_dpms() causes a crash when the
> connectors atomic state is not initialized. The patch implements a
> driver specific connector dpms helper that calls
> drm_atomic_helper_connector_dpms() if driver supports DRIVER_ATOMIC
> and otherwise it calls the legacy drm_helper_connector_dpms().
>
> Fixes commit 9736e988d328 ("drm/i2c: tda998x: Add support for atomic
> modesetting").
>
> Signed-off-by: Jyri Sarha 
> ---
>
> Ok, so this is the second approach to solve this issue. The first
> attempt can be found here [1] with the follow from Liviu Dudau that
> suggested this approach.
>
> It just makes me wonder if drm_atomic_helper_connector_dpms() should
> call the legacy callback automatically if DRIVER_ATOMIC is not set or
> at least bail out gracefully with an error message. Then again it may
> be overkill if the tda998x is the only driver that need to support
> both situations.
>
> Best regards,
> Jyri
>
> [1] http://www.spinics.net/lists/dri-devel/msg98514.html
>
>   drivers/gpu/drm/i2c/tda998x_drv.c | 10 +-
>   1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 012d36d..bb7d507 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1382,8 +1382,16 @@ static void tda998x_connector_destroy(struct 
> drm_connector *connector)
>   drm_connector_cleanup(connector);
>   }
>
> +static int tda998x_connector_dpms(struct drm_connector *connector, int mode)
> +{
> + if (drm_core_check_feature(connector->dev, DRIVER_ATOMIC))
> + return drm_atomic_helper_connector_dpms(connector, mode);
> + else
> + return drm_helper_connector_dpms(connector, mode);
> +}
> +
>   static const struct drm_connector_funcs tda998x_connector_funcs = {
> - .dpms = drm_atomic_helper_connector_dpms,
> + .dpms = tda998x_connector_dpms,
>   .reset = drm_atomic_helper_connector_reset,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .detect = tda998x_connector_detect,
>

[PATCH] drm/radeon: refactor CIK tiling table initialization

[Deucher, Alexander]

> -Original Message-
> From: Josh Poimboeuf [mailto:jpoimboe at redhat.com]
> Sent: Monday, March 07, 2016 6:10 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; 
> kbuild
> test robot; Ingo Molnar
> Subject: [PATCH] drm/radeon: refactor CIK tiling table initialization
> 
> When compiling the radeon driver on x86_64 with
> CONFIG_STACK_VALIDATION
> enabled, objtool gives the following warnings:
> 
>   drivers/gpu/drm/radeon/cik.o: warning: objtool:
> cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup
>   drivers/gpu/drm/radeon/cik.o: warning: objtool:
> cik_tiling_mode_table_init()+0x72b: call without frame pointer save/setup
>   drivers/gpu/drm/radeon/cik.o: warning: objtool:
> cik_tiling_mode_table_init()+0x464: call without frame pointer save/setup
>   ...
> 
> These are actually false positive warnings; there are no frame pointer
> bugs.  Instead objtool gets confused by the jump tables created by all
> the switch statements, combined with some other gcc optimizations.  It
> tries to follows all possible code paths, but it fails to realize that
> some of the paths aren't possible.  For example:
> 
> 4c97:   31 c0   xor%eax,%eax
> ...
> 4ca2:   89 c1   mov%eax,%ecx
> 4ca4:   ff 24 cd 00 00 00 00jmpq   *0x0(,%rcx,8) 4ca7: 
> R_X86_64_32S
> .rodata+0x148
> 
> First eax is cleared to zero with the "xor %eax,%eax" instruction.
> Later, it moves the value of eax (zero in this case) to ecx, and uses
> that value to jump to the first entry in a jump table in .rodata.
> 
> Because objtool doesn't have an x86 emulator, it doesn't know that rcx
> is zero.  So instead of following a single code path to the first jump
> table entry, it follows all possible jump table entry paths in parallel.
> 
> Usually such overactive analysis isn't a problem.  In every other jump
> table in the kernel, all the jump targets have the same frame pointer
> state.  But in this exceedingly rare case, different targets have
> different frame pointer states.  Objtool notices that and creates the
> false positive warnings.
> 
> In theory we could use the STACK_FRAME_NON_STANDARD marker to tell
> objtool to skip analysis of the function.  However, that's less than
> ideal.
> 
> Looking at the cik_tiling_mode_table_init() code, it seems overly
> complex with lots of repetition.  So let's simplify it.  All the switch
> statements and conditionals can be replaced with much simpler logic by
> generalizing the different behaviors and moving the initialization data
> into data structures.
> 
> The change is a win-win: it's easier to parse for both humans and
> machines.  It also reduces the binary size by about 2%:
> 
>  textdata bss dec hex filename
>101011   30360   0  131371   2012b cik-before.o
> 98699   30200   0  128899   1f783 cik-after.o
> 
> [ Note: Unfortunately I don't know how to test this code, so it's
>   completely untested.  Any help or guidance with ensuring that the
>   correct initialization is still being written would be greatly
>   appreciated! ]

I think it would be clearer to rework it similarly to how it was reworked in 
amdgpu (see gfx_v8_0.c and gfx_v7_0.c in drm-next).  Also ideally you'd update 
the similar code in si.c as well for consistency.

Alex

[Bug 113951] Kernel bug in AMDGPU

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

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

--- Comment #2 from Alex Deucher  ---
Created attachment 208101
  --> https://bugzilla.kernel.org/attachment.cgi?id=208101=edit
fix

This patch should fix it.

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

boot hang with vmwgfx on 4.5-rc6

[Sebastian Herbszt]

Thomas Hellstrom wrote:
> Hi, Daniel,
> 
> It appears you and Thierry are guilty to this:
> 
> d56f57ac969c7818986a0c78025740399e49f3a9

Looks like Jongman Heo did also report this issue [1][2].

> Could you please revert the vmwgfx-specific parts of that commit before
> 4.5 GA?
> 
> Thanks,
> Thomas

[1] http://marc.info/?l=linux-kernel=145317572914973=2
[2] http://marc.info/?l=linux-kernel=145559056816583=2

Sebastian

[PATCH 3/3] ARM: bcm2835: Add VC4 to the device tree.

[Stephen Warren]

On 03/04/2016 01:32 PM, Eric Anholt wrote:
> VC4 is the GPU (display and 3D) present on the 283x.

> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts 
> b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts

> + {
> + hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
> +};

Isn't that the same everywhere? If so, adding it to bcm2835-rpi.dtsi 
seems like a better idea; it'd avoid duplicating it everywhere.

[Bug 113951] Kernel bug in AMDGPU

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Looks like this stable patch applied incorrectly:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.4.y=d60703ca942e8d044d61360bc9792fcab54b95d0

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

[Bug 113951] New: Kernel bug in AMDGPU

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

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

Bug ID: 113951
   Summary: Kernel bug in AMDGPU
   Product: Drivers
   Version: 2.5
Kernel Version: 4.4.4
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: ycdmdj at gmail.com
Regression: No

Created attachment 208091
  --> https://bugzilla.kernel.org/attachment.cgi?id=208091=edit
stacktrace of bug

I am running ArchLinux testing kernel 4.4.4-1 and got stuck on early boot when
switching to amdgpudrmfb. Previous version 4.4.3 works fine. Sending relevant
journal part.

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

[PATCH] drm/vmwgfx: Add back ->detect() and ->fill_modes()

[Thomas Hellstrom]

Tested-by: Thomas Hellstrom 


On 03/07/2016 06:06 PM, Thierry Reding wrote:
> From: Thierry Reding 
>
> This partially reverts commit d56f57ac969c ("drm/gma500: Move to private
> save/restore hooks") which removed these lines by mistake.
>
> Reported-by: Sebastian Herbszt 
> Acked-by: Daniel Vetter 
> Signed-off-by: Thierry Reding 
> ---
> Hi Dave,
>
> Daniel and I introduced this in v4.5-rc1, so it'd be good to have this
> go into v4.5 final once Sebastian and Thomas have confirmed that it is
> fixed.
>
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index db082bea8daf..c5a1a08b0449 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -563,6 +563,8 @@ static void vmw_sou_connector_destroy(struct 
> drm_connector *connector)
>  
>  static const struct drm_connector_funcs vmw_sou_connector_funcs = {
>   .dpms = vmw_du_connector_dpms,
> + .detect = vmw_du_connector_detect,
> + .fill_modes = vmw_du_connector_fill_modes,
>   .set_property = vmw_du_connector_set_property,
>   .destroy = vmw_sou_connector_destroy,
>  };

[Bug 94405] radeon GPU hang

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

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

Lorenzo Bona  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

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

[PATCH] drm/vmwgfx: Add back ->detect() and ->fill_modes()

[Daniel Vetter]

On Mon, Mar 7, 2016 at 6:06 PM, Thierry Reding  
wrote:
> From: Thierry Reding 
>
> This partially reverts commit d56f57ac969c ("drm/gma500: Move to private
> save/restore hooks") which removed these lines by mistake.
>
> Reported-by: Sebastian Herbszt 
> Acked-by: Daniel Vetter 
> Signed-off-by: Thierry Reding 
> ---
> Hi Dave,
>
> Daniel and I introduced this in v4.5-rc1, so it'd be good to have this
> go into v4.5 final once Sebastian and Thomas have confirmed that it is
> fixed.

Yeah, sorry for the silly mistake - no idea any more how that crept
in, there's no pending patch series at all even touching these hooks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Atomic mode-setting drivers

[Chih-Wei Huang]

2016-03-05 0:32 GMT+08:00 Daniel Vetter :
> Adding relevant mailing lists and people. Please don't send private
> mails to maintainers ;-)

Thank you for the reply and pointing it.

> On Fri, Mar 4, 2016 at 1:47 PM, Chih-Wei Huang  
> wrote:
>> Hi Daniel,
>> This is the Android-x86 project.
>> I'm looking for info about atomic mode-setting drivers
>> and then found your presentation at
>> http://www.x.org/wiki/Events/XDC2015/Program/xdc-2015.pdf
>>
>> Especially page 16 talks about the Android support,
>> exactly what I want.
>>
>> It said "no one has an open-source atomic hwc".
>> Actually there is one in the AOSP 6.0 release:
>>
>> https://android.googlesource.com/platform/external/drm_hwcomposer
>>
>> It's developed by the Chromium team.
>> An update repo is here:
>> https://chromium.googlesource.com/chromiumos/drm_hwcomposer
>
> Yup, my presentation is already outdated - the latest one for LCA2016
> mentions that hwc exists.

Thanks! Do you have a link for it?

>> Contributing instructions are here:
>> https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer
>>
>> We are trying to enable the drm_hwcomposer for Android-x86.
>> However, it requires atomic mode-setting drivers
>> which seems are not ready in the vanilla kernel 4.4,
>> the kernel we are using now.
>>
>> Unfortunately none of us is an expert of kernel drm drivres.
>> Could you give me a brief status of the
>> current atomic mode-setting drivers in vanilla kernel?
>> What are still missing? fences? deadlock?
>> More important, how much effort do we need
>> to make them work with AOSP's drm_hwcomposer?
>
> There's a pile of drivers, but for classic x86 desktop only i915.ko,
> and that is still not yet enabled by default. i915.nuclear_pageflip=1
> will give you experimental atomic support but not sure whether that's
> good enough for hwcomposer.

Yes. I've tried i915.nuclear_pageflip=1
(before sent you the email)
The atomic call pass, but I got further errors:

02-25 17:37:28.320  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.320  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.321  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.321  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.321  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.322  1641  1641 I hwc-drm-plane: Could not get alpha property
02-25 17:37:28.323  1641  1641 E hwc-drm-resources: Could not find a
suitable encoder/crtc for display 3
02-25 17:37:28.323  1641  1641 E hwc-drm-resources: Failed
CreateDisplayPipe 47 with -19
02-25 17:37:28.323  1641  1641 E hwcomposer-drm: Can't initialize Drm object -19

Still black screen.

The other x86 drivers I've tried are radeon and vmwgfx.
Both seems don't support atomic mode-setting yet.

The only x86 GPU works with drm_hwcomposer
is virgl (with patches by Rob Herring).

> Fences are being worked on in upstream kernel, but nothing to show
> yet.. Otherwise I don't know what's all needed to make it, I haven't
> had a chance to play around with it yet.
>
>> More discussion about it can be found in
>> our devel group:
>> https://groups.google.com/d/msg/android-x86-devel/RErWaXk3b7g/g_OSPGf4AwAJ
>
> Please include that mailing list too, to make sure everyone is on board.

Included. Thanks!

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

[Jani Nikula]

On Mon, 07 Mar 2016, Martin Kepplinger  wrote:
> This still isn't merged but still fixes a serious regression in v4.5.
> What's going on?

Bumps in the CI road. Now pushed to drm-intel-next-queued and
cherry-picked to drm-intel-fixes, en route to v4.5. Thanks for the
patch, review, and testing.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

[Heiko Stübner]

Hi Doug,

Am Montag, 7. März 2016, 10:49:53 schrieb Doug Anderson:
> On Mon, Mar 7, 2016 at 9:57 AM, Heiko Stübner  wrote:
> > Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
> >> Hi,
> >> 
> >> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao  
wrote:
> >> > On 2016年03月05日 20:39, Russell King - ARM Linux wrote:
> >> >> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
> >> >>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
> >>  The drm_encoder_cleanup() was missing both from the error path of
> >>  dw_hdmi_rockchip_bind().  This caused a crash when slub_debug was
> >>  enabled and we ended up deferring probe of HDMI at boot.
> >>  
> >>  This call isn't needed from unbind() because if dw_hdmi_bind()
> >>  returns
> >>  no error then it takes over the job of freeing the encoder (in
> >>  dw_hdmi_unbind).
> >>  
> >>  Signed-off-by: Douglas Anderson 
> >>  ---
> >> >>> 
> >> >>> Does dw_hdmi-imx need a similar change?  I wonder if it would be
> >> >>> cleaner
> >> >>> to push this into dw_hdmi_bind() if it affects all of the platforms..
> >> >> 
> >> >> I don't think moving it there would make sense - keep the
> >> >> initialisation
> >> >> and cleanup together in the same file so that it's contained together.
> >> > 
> >> > I don't like this patch too, initialisation and cleanup not in the same
> >> > file looks bad,
> >> > 
> >> > How about:
> >> > 
> >> > drivers/gpu/drm/bridge/dw-hdmi.c
> >> > void dw_hdmi_unbind(struct device *dev, struct device *master, void
> >> > *data)
> >> > 
> >> > hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
> >> > 
> >> > hdmi->connector.funcs->destroy(>connector);
> >> > -   hdmi->encoder->funcs->destroy(hdmi->encoder);
> >> > 
> >> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> >> > static int dw_hdmi_rockchip_bind(struct device *dev, struct device
> >> > *master,
> >> > 
> >> > -   return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> >> > plat_data);
> >> > +   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> >> > plat_data);
> >> > +   if (ret)
> >> > +   drm_encoder_cleanup(encoder);
> >> > +
> >> > +   return ret;
> >> > 
> >> >  }
> >> >  
> >> >  static void dw_hdmi_rockchip_unbind(struct device *dev, struct device
> >> > 
> >> > *master,
> >> > 
> >> > void *data)
> >> >  
> >> >  {
> >> > 
> >> > +   drm_encoder_cleanup(...);
> >> > 
> >> > return dw_hdmi_unbind(dev, master, data);
> >> >  
> >> >  }
> >> 
> >> That'a a reasonable suggestion in theory.  ...but we run into the same
> >> problem I've run into before with the strange relationship between
> >> dw_hdmi and its descendants.
> > 
> > I don't think handing off the cleanup responsibility is really in question
> > here. I.e. I do believe it should also be fine to expect (as definition)
> > the core driver to cleanup the encoder _after_ it sucessfully claimed it
> > in dw_hdmi_bind().
> > 
> > We do the same in the rockchip power-domains, handing off the struct clk-
> > pointer to the pm_clk stuff (due to the clk-pointer being unique
> > per-device
> > nowadays).
> > 
> > So just making sure it is sucessfully handed off should also be ok.
> 
> If I understand correctly, that means you'd be OK with the original
> patch I posted?  In that case cleanup continues to happen in the main
> dw-hdmi.c if dw_hdmi_bind() succeeds and my patch fixes the cleanup
> when dw_hdmi_bind() fails (and thus cleanup responsibility was not
> handed off).

correct. I don't see the need to duplicate the cleanup (+added infrastructure 
to actually get the encoder in unbind) in all instances, if we just define that 
the dw_hdmi core takes control of the encoder _after_ it sucessfully bound.

So only if dw_hdmi_bind() fails does the hw-specific instance need to clean up 
the encoder it created.


> Also: I noticed that Russell also didn't seem to say that my original
> patch was bad.  I think he just said that he didn't like John
> Keeping's suggestion.

that was my reading as well.


Heiko

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

[Russell King - ARM Linux]

On Mon, Mar 07, 2016 at 07:56:18PM +0100, Heiko Stübner wrote:
> Hi Doug,
> 
> Am Montag, 7. März 2016, 10:49:53 schrieb Doug Anderson:
> > On Mon, Mar 7, 2016 at 9:57 AM, Heiko Stübner  wrote:
> > > Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
> > >> Hi,
> > >> 
> > >> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao  
> wrote:
> > >> > On 2016年03月05日 20:39, Russell King - ARM Linux wrote:
> > >> >> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
> > >> >>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
> > >>  The drm_encoder_cleanup() was missing both from the error path of
> > >>  dw_hdmi_rockchip_bind().  This caused a crash when slub_debug was
> > >>  enabled and we ended up deferring probe of HDMI at boot.
> > >>  
> > >>  This call isn't needed from unbind() because if dw_hdmi_bind()
> > >>  returns
> > >>  no error then it takes over the job of freeing the encoder (in
> > >>  dw_hdmi_unbind).
> > >>  
> > >>  Signed-off-by: Douglas Anderson 
> > >>  ---
> > >> >>> 
> > >> >>> Does dw_hdmi-imx need a similar change?  I wonder if it would be
> > >> >>> cleaner
> > >> >>> to push this into dw_hdmi_bind() if it affects all of the platforms..
> > >> >> 
> > >> >> I don't think moving it there would make sense - keep the
> > >> >> initialisation
> > >> >> and cleanup together in the same file so that it's contained together.
> > >> > 
> > >> > I don't like this patch too, initialisation and cleanup not in the same
> > >> > file looks bad,
> > >> > 
> > >> > How about:
> > >> > 
> > >> > drivers/gpu/drm/bridge/dw-hdmi.c
> > >> > void dw_hdmi_unbind(struct device *dev, struct device *master, void
> > >> > *data)
> > >> > 
> > >> > hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
> > >> > 
> > >> > hdmi->connector.funcs->destroy(>connector);
> > >> > -   hdmi->encoder->funcs->destroy(hdmi->encoder);
> > >> > 
> > >> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > >> > static int dw_hdmi_rockchip_bind(struct device *dev, struct device
> > >> > *master,
> > >> > 
> > >> > -   return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> > >> > plat_data);
> > >> > +   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> > >> > plat_data);
> > >> > +   if (ret)
> > >> > +   drm_encoder_cleanup(encoder);
> > >> > +
> > >> > +   return ret;
> > >> > 
> > >> >  }
> > >> >  
> > >> >  static void dw_hdmi_rockchip_unbind(struct device *dev, struct device
> > >> > 
> > >> > *master,
> > >> > 
> > >> > void *data)
> > >> >  
> > >> >  {
> > >> > 
> > >> > +   drm_encoder_cleanup(...);
> > >> > 
> > >> > return dw_hdmi_unbind(dev, master, data);
> > >> >  
> > >> >  }
> > >> 
> > >> That'a a reasonable suggestion in theory.  ...but we run into the same
> > >> problem I've run into before with the strange relationship between
> > >> dw_hdmi and its descendants.
> > > 
> > > I don't think handing off the cleanup responsibility is really in question
> > > here. I.e. I do believe it should also be fine to expect (as definition)
> > > the core driver to cleanup the encoder _after_ it sucessfully claimed it
> > > in dw_hdmi_bind().
> > > 
> > > We do the same in the rockchip power-domains, handing off the struct clk-
> > > pointer to the pm_clk stuff (due to the clk-pointer being unique
> > > per-device
> > > nowadays).
> > > 
> > > So just making sure it is sucessfully handed off should also be ok.
> > 
> > If I understand correctly, that means you'd be OK with the original
> > patch I posted?  In that case cleanup continues to happen in the main
> > dw-hdmi.c if dw_hdmi_bind() succeeds and my patch fixes the cleanup
> > when dw_hdmi_bind() fails (and thus cleanup responsibility was not
> > handed off).
> 
> correct. I don't see the need to duplicate the cleanup (+added infrastructure 
> to actually get the encoder in unbind) in all instances, if we just define 
> that 
> the dw_hdmi core takes control of the encoder _after_ it sucessfully bound.
> 
> So only if dw_hdmi_bind() fails does the hw-specific instance need to clean 
> up 
> the encoder it created.
> 
> 
> > Also: I noticed that Russell also didn't seem to say that my original
> > patch was bad.  I think he just said that he didn't like John
> > Keeping's suggestion.
> 
> that was my reading as well.

The core code does not create the encoder - it merely stores a pointer
to the encoder, and registers itself as a bridge against the encoder.
It does call drm_mode_connector_attach_encoder() which adds the
encoder ID to the connector's possible encoders.

The cleanup (in dw_hdmi_unbind()) really ought to be moved out, but
that adds problems because of the need for two lots of driver data
to then be stored.

However, the bind() path really needs to be doing the encoder cleanup
before returning when an unsuccessful dw_hdmi_bind() returns.  I
wouldn't be surprised if there's a 

Linux 4.4.4 [regression]

[Jörg-Volker Peetz]

Deucher, Alexander wrote on 03/07/16 19:07:
>> -Original Message-
>> From: Jörg-Volker Peetz [mailto:jvpeetz at web.de]
>> Sent: Monday, March 07, 2016 12:40 PM
>> To: Deucher, Alexander; 'Linus Torvalds'; Dave Airlie; DRI mailing list
>> Cc: Greg KH; Linux Kernel Mailing List; stable; lwn at lwn.net; Andrew 
>> Morton;
>> Jiri Slaby
>> Subject: Re: Linux 4.4.4 [regression]
>>
>> Deucher, Alexander wrote on 03/07/16 17:44:
 -Original Message-
 From: linus971 at gmail.com [mailto:linus971 at gmail.com] On Behalf Of
>> Linus
 Torvalds
 Sent: Monday, March 07, 2016 11:21 AM
 To: Jörg-Volker Peetz; Dave Airlie; DRI mailing list
 Cc: Greg KH; Linux Kernel Mailing List; Andrew Morton; stable;
>> lwn at lwn.net;
 Jiri Slaby; Deucher, Alexander
 Subject: Re: Linux 4.4.4 [regression]

 On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz 
 wrote:
>
> This same problem with X does happen in 4.5-rc7. And removing the line
> introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1
>> makes
 X go again on
> my laptop.

 Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainline.

 Dave, Alex: that commit makes Jörg-Volker's HP Pavilion dv7 with
 hybrid graphics (AMD HD 4200 - AMD 5400) unable to run X. No
 suspend/resume in sight, just starting X hangs.

 I'd guess it's the "radeon_switcheroo_set_state()" craziness (based on
 that hybrid graphics thing), but we need to do something since this is
 a regression.

 Just revert for now? Or do you have other suggestions for Jörg-Volker to
 test?
>>>
>>> Can you attach your dmesg output?
>>>
>> I append the dmesg output from 4.5-rc7 (as vacuous as it is) and from my
>> running
>> system with 4.4.4 without the problematic code line.
>> Will try your attached patch next.
> 
> Thanks.  The patch won't make any difference in the case of your system.  It 
> looks like you have a muxed system so I suspect what's happening is that one 
> of the display is being reported as connected for both the IGP and the dGPU 
> and then the desktop environment gets confused or there some sort problem in 
> the detect functions since the mux is not switched to the dGPU.  I don't see 
> an easy fix unless Dave has any ideas.  I'd say just revert for now. 
> 
> Alex
> 

Yes, your last patch doesn't help.
For completeness and since it contains some more lines, I append its dmesg also.

Regards,
jvp.


-- next part --
Linux version 4.5.0-rc7-dirty (root at uruz) (gcc version 5.3.1 20160224 
(Debian 5.3.1-10) ) #17 SMP Mon Mar 7 18:59:18 CET 2016
Command line: BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 ro pcie_aspm=force 
radeon.audio=1 radeon.dpm=1
tseg: 00cff0
x86/fpu: Legacy x87 FPU detected.
x86/fpu: Using 'lazy' FPU context switches.
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xce447fff] usable
BIOS-e820: [mem 0xce448000-0xce647fff] ACPI NVS
BIOS-e820: [mem 0xce648000-0xcfd3efff] usable
BIOS-e820: [mem 0xcfd3f000-0xcfdbefff] reserved
BIOS-e820: [mem 0xcfdbf000-0xcfebefff] ACPI NVS
BIOS-e820: [mem 0xcfebf000-0xcfef5fff] ACPI data
BIOS-e820: [mem 0xcfef6000-0xcfef] usable
BIOS-e820: [mem 0xf700-0xf7ff] reserved
BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xffe0-0x] reserved
BIOS-e820: [mem 0x0001-0x00021fff] usable
NX (Execute Disable) protection: active
SMBIOS 2.6 present.
DMI: Hewlett-Packard HP Pavilion dv7 Notebook PC/1443, BIOS F.23 11/11/2010
e820: update [mem 0x-0x0fff] usable ==> reserved
e820: remove [mem 0x000a-0x000f] usable
AGP: No AGP bridge found
e820: last_pfn = 0x22 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-E write-through
  F-F write-protect
MTRR variable ranges enabled:
  0 base  mask 8000 write-back
  1 base 8000 mask C000 write-back
  2 base C000 mask F000 write-back
  3 base FFE0 mask FFE0 write-protect
  4 base 0001 mask  write-back
  5 base 0002 mask E000 write-back
  6 disabled
  7 disabled
TOM2: 00023000 aka 8960M
x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
e820: last_pfn = 0xcff00 max_arch_pfn = 0x4
Base memory trampoline at [88099000] 99000 

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

[Heiko Stübner]

Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
> Hi,
> 
> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao  wrote:
> > On 2016年03月05日 20:39, Russell King - ARM Linux wrote:
> >> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
> >>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
>  The drm_encoder_cleanup() was missing both from the error path of
>  dw_hdmi_rockchip_bind().  This caused a crash when slub_debug was
>  enabled and we ended up deferring probe of HDMI at boot.
>  
>  This call isn't needed from unbind() because if dw_hdmi_bind() returns
>  no error then it takes over the job of freeing the encoder (in
>  dw_hdmi_unbind).
>  
>  Signed-off-by: Douglas Anderson 
>  ---
> >>> 
> >>> Does dw_hdmi-imx need a similar change?  I wonder if it would be cleaner
> >>> to push this into dw_hdmi_bind() if it affects all of the platforms..
> >> 
> >> I don't think moving it there would make sense - keep the initialisation
> >> and cleanup together in the same file so that it's contained together.
> > 
> > I don't like this patch too, initialisation and cleanup not in the same
> > file looks bad,
> > 
> > How about:
> > 
> > drivers/gpu/drm/bridge/dw-hdmi.c
> > void dw_hdmi_unbind(struct device *dev, struct device *master, void *data)
> > 
> > hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
> > 
> > hdmi->connector.funcs->destroy(>connector);
> > -   hdmi->encoder->funcs->destroy(hdmi->encoder);
> > 
> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > static int dw_hdmi_rockchip_bind(struct device *dev, struct device
> > *master,
> > 
> > -   return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> > plat_data);
> > +   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> > plat_data);
> > +   if (ret)
> > +   drm_encoder_cleanup(encoder);
> > +
> > +   return ret;
> > 
> >  }
> >  
> >  static void dw_hdmi_rockchip_unbind(struct device *dev, struct device
> > 
> > *master,
> > 
> > void *data)
> >  
> >  {
> > 
> > +   drm_encoder_cleanup(...);
> > 
> > return dw_hdmi_unbind(dev, master, data);
> >  
> >  }
> 
> That'a a reasonable suggestion in theory.  ...but we run into the same
> problem I've run into before with the strange relationship between
> dw_hdmi and its descendants.

I don't think handing off the cleanup responsibility is really in question 
here. I.e. I do believe it should also be fine to expect (as definition) the 
core driver to cleanup the encoder _after_ it sucessfully claimed it in 
dw_hdmi_bind().

We do the same in the rockchip power-domains, handing off the struct clk-
pointer to the pm_clk stuff (due to the clk-pointer being unique per-device 
nowadays).

So just making sure it is sucessfully handed off should also be ok.


Heiko

> 
> Specifically:
> 
> * "struct dw_hdmi", which has a pointer to encoder, is private to dw-hdmi.c
> 
> * We could get the encoder if we had a pointer to the "struct
> rockchip_hdmi", but there's no way to get that.  You would _think_ you
> could get it back using platform_get_drvdata() because it was stashed
> with platform_set_drvdata().  ...but you'd be wrong.  The
> platform_set_drvdata() is just there to fool you.  I believe when you
> call dw_hdmi_bind() it clobbers your drvdata when it calls
> dev_set_drvdata(dev, hdmi);
> 
> 
> Said another way: taking your suggestion means we need to add some way
> for dw_hdmi-rockchip.c to get a pointer to the encoder from a "struct
> device".  We could (A) move the "struct dw_hdmi" definition to a
> private header and allow dw_hdmi-rockchip.c to include it or we could
> (B) add a dw_hdmi_get_encoder() API call that dw_hdmi-rockchip.c could
> call.
> 
> 
> If someone would let me know whether (A) or (B) is OK I'm happy to post a
> patch.
> 
> 
> ...or, of course, if I've made a mistake in all the above, feel free
> to point it out.
> 
> 
> -Doug

[PATCH 2/2] drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.

[Alex Deucher]

On Sat, Mar 5, 2016 at 8:39 PM, Mario Kleiner
 wrote:
> As observed on Apple iMac10,1, DCE-3.2, RV-730,
> link rate of 2.7 Ghz is not selected, because
> the args.v1.ucConfig flag setting for 2.7 Ghz
> gets overwritten by a following assignment of
> the transmitter to use.
>
> Move link rate setup a few lines down to fix this.
> In practice this didn't have any positive or
> negative effect on display setup on the tested
> iMac10,1 so i don't know if backporting to stable
> makes sense or not.
>
> Signed-off-by: Mario Kleiner 

Applied, and yes, this should go to stable.

Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/atombios_encoders.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index a28377c..dc1e810 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -892,8 +892,6 @@ atombios_dig_encoder_setup2(struct drm_encoder *encoder, 
> int action, int panel_m
> else
> args.v1.ucLaneNum = 4;
>
> -   if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) && 
> (dp_clock == 27))
> -   args.v1.ucConfig |= 
> ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ;
> switch (radeon_encoder->encoder_id) {
> case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
> args.v1.ucConfig = 
> ATOM_ENCODER_CONFIG_V2_TRANSMITTER1;
> @@ -910,6 +908,10 @@ atombios_dig_encoder_setup2(struct drm_encoder *encoder, 
> int action, int panel_m
> args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKB;
> else
> args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKA;
> +
> +   if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) && 
> (dp_clock == 27))
> +   args.v1.ucConfig |= 
> ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ;
> +
> break;
> case 2:
> case 3:
> --
> 2.7.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 4.4.4 [regression]

[Jörg-Volker Peetz]

Deucher, Alexander wrote on 03/07/16 17:44:
>> -Original Message-
>> From: linus971 at gmail.com [mailto:linus971 at gmail.com] On Behalf Of Linus
>> Torvalds
>> Sent: Monday, March 07, 2016 11:21 AM
>> To: Jörg-Volker Peetz; Dave Airlie; DRI mailing list
>> Cc: Greg KH; Linux Kernel Mailing List; Andrew Morton; stable; lwn at 
>> lwn.net;
>> Jiri Slaby; Deucher, Alexander
>> Subject: Re: Linux 4.4.4 [regression]
>>
>> On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz 
>> wrote:
>>>
>>> This same problem with X does happen in 4.5-rc7. And removing the line
>>> introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 makes
>> X go again on
>>> my laptop.
>>
>> Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainline.
>>
>> Dave, Alex: that commit makes Jörg-Volker's HP Pavilion dv7 with
>> hybrid graphics (AMD HD 4200 - AMD 5400) unable to run X. No
>> suspend/resume in sight, just starting X hangs.
>>
>> I'd guess it's the "radeon_switcheroo_set_state()" craziness (based on
>> that hybrid graphics thing), but we need to do something since this is
>> a regression.
>>
>> Just revert for now? Or do you have other suggestions for Jörg-Volker to
>> test?
> 
> Can you attach your dmesg output?
> 
I append the dmesg output from 4.5-rc7 (as vacuous as it is) and from my running
system with 4.4.4 without the problematic code line.
Will try your attached patch next.

Regards,
jvp.

-- next part --
Linux version 4.5.0-rc7 (root at uruz) (gcc version 5.3.1 20160224 (Debian 
5.3.1-10) ) #15 SMP Mon Mar 7 11:51:26 CET 2016
Command line: BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 ro pcie_aspm=force 
radeon.audio=1 radeon.dpm=1
tseg: 00cff0
x86/fpu: Legacy x87 FPU detected.
x86/fpu: Using 'lazy' FPU context switches.
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xce447fff] usable
BIOS-e820: [mem 0xce448000-0xce647fff] ACPI NVS
BIOS-e820: [mem 0xce648000-0xcfd3efff] usable
BIOS-e820: [mem 0xcfd3f000-0xcfdbefff] reserved
BIOS-e820: [mem 0xcfdbf000-0xcfebefff] ACPI NVS
BIOS-e820: [mem 0xcfebf000-0xcfef5fff] ACPI data
BIOS-e820: [mem 0xcfef6000-0xcfef] usable
BIOS-e820: [mem 0xf700-0xf7ff] reserved
BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xffe0-0x] reserved
BIOS-e820: [mem 0x0001-0x00021fff] usable
NX (Execute Disable) protection: active
SMBIOS 2.6 present.
DMI: Hewlett-Packard HP Pavilion dv7 Notebook PC/1443, BIOS F.23 11/11/2010
e820: update [mem 0x-0x0fff] usable ==> reserved
e820: remove [mem 0x000a-0x000f] usable
AGP: No AGP bridge found
e820: last_pfn = 0x22 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-E write-through
  F-F write-protect
MTRR variable ranges enabled:
  0 base  mask 8000 write-back
  1 base 8000 mask C000 write-back
  2 base C000 mask F000 write-back
  3 base FFE0 mask FFE0 write-protect
  4 base 0001 mask  write-back
  5 base 0002 mask E000 write-back
  6 disabled
  7 disabled
TOM2: 00023000 aka 8960M
x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
e820: last_pfn = 0xcff00 max_arch_pfn = 0x4
Base memory trampoline at [88099000] 99000 size 24576
Using GB pages for direct mapping
BRK [0x01901000, 0x01901fff] PGTABLE
BRK [0x01902000, 0x01902fff] PGTABLE
BRK [0x01903000, 0x01903fff] PGTABLE
BRK [0x01904000, 0x01904fff] PGTABLE
BRK [0x01905000, 0x01905fff] PGTABLE
BRK [0x01906000, 0x01906fff] PGTABLE
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000FE020 24 (v02 HP)
ACPI: XSDT 0xCFEF5120 5C (v01 HPQOEM SLIC-MPC 0003  
0113)
ACPI: FACP 0xCFEF4000 F4 (v04 HP 1443 0003 MSFT 
0113)
ACPI: DSDT 0xCFEE2000 00E0D7 (v01 HP 1443 F000 MSFT 
0113)
ACPI: FACS 0xCFE9C000 40
ACPI: FACS 0xCFE9C000 40
ACPI: HPET 0xCFEF3000 38 (v01 HP 1443 0001 MSFT 
0113)
ACPI: APIC 0xCFEF2000 84 (v02 HP 1443 0001 MSFT 
0113)
ACPI: MCFG 0xCFEF1000 3C (v01 HP 1443 0001 MSFT 
0113)
ACPI: BOOT 0xCFEE1000 28 (v01 HP 1443 0001 MSFT 
0113)
ACPI: SLIC 0xCFEE 000176 (v01 HPQOEM SLIC-MPC 

Linux 4.4.4 [regression]

[Deucher, Alexander]

> -Original Message-
> From: Jörg-Volker Peetz [mailto:jvpeetz at web.de]
> Sent: Monday, March 07, 2016 12:40 PM
> To: Deucher, Alexander; 'Linus Torvalds'; Dave Airlie; DRI mailing list
> Cc: Greg KH; Linux Kernel Mailing List; stable; lwn at lwn.net; Andrew Morton;
> Jiri Slaby
> Subject: Re: Linux 4.4.4 [regression]
> 
> Deucher, Alexander wrote on 03/07/16 17:44:
> >> -Original Message-
> >> From: linus971 at gmail.com [mailto:linus971 at gmail.com] On Behalf Of
> Linus
> >> Torvalds
> >> Sent: Monday, March 07, 2016 11:21 AM
> >> To: Jörg-Volker Peetz; Dave Airlie; DRI mailing list
> >> Cc: Greg KH; Linux Kernel Mailing List; Andrew Morton; stable;
> lwn at lwn.net;
> >> Jiri Slaby; Deucher, Alexander
> >> Subject: Re: Linux 4.4.4 [regression]
> >>
> >> On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz 
> >> wrote:
> >>>
> >>> This same problem with X does happen in 4.5-rc7. And removing the line
> >>> introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1
> makes
> >> X go again on
> >>> my laptop.
> >>
> >> Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainline.
> >>
> >> Dave, Alex: that commit makes Jörg-Volker's HP Pavilion dv7 with
> >> hybrid graphics (AMD HD 4200 - AMD 5400) unable to run X. No
> >> suspend/resume in sight, just starting X hangs.
> >>
> >> I'd guess it's the "radeon_switcheroo_set_state()" craziness (based on
> >> that hybrid graphics thing), but we need to do something since this is
> >> a regression.
> >>
> >> Just revert for now? Or do you have other suggestions for Jörg-Volker to
> >> test?
> >
> > Can you attach your dmesg output?
> >
> I append the dmesg output from 4.5-rc7 (as vacuous as it is) and from my
> running
> system with 4.4.4 without the problematic code line.
> Will try your attached patch next.

Thanks.  The patch won't make any difference in the case of your system.  It 
looks like you have a muxed system so I suspect what's happening is that one of 
the display is being reported as connected for both the IGP and the dGPU and 
then the desktop environment gets confused or there some sort problem in the 
detect functions since the mux is not switched to the dGPU.  I don't see an 
easy fix unless Dave has any ideas.  I'd say just revert for now. 

Alex

[PATCH] drm/vmwgfx: Add back ->detect() and ->fill_modes()

[Thierry Reding]

From: Thierry Reding 

This partially reverts commit d56f57ac969c ("drm/gma500: Move to private
save/restore hooks") which removed these lines by mistake.

Reported-by: Sebastian Herbszt 
Acked-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
Hi Dave,

Daniel and I introduced this in v4.5-rc1, so it'd be good to have this
go into v4.5 final once Sebastian and Thomas have confirmed that it is
fixed.

 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index db082bea8daf..c5a1a08b0449 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -563,6 +563,8 @@ static void vmw_sou_connector_destroy(struct drm_connector 
*connector)

 static const struct drm_connector_funcs vmw_sou_connector_funcs = {
.dpms = vmw_du_connector_dpms,
+   .detect = vmw_du_connector_detect,
+   .fill_modes = vmw_du_connector_fill_modes,
.set_property = vmw_du_connector_set_property,
.destroy = vmw_sou_connector_destroy,
 };
-- 
2.7.1

[GIT PULL] etnaviv for 4.6

[Lucas Stach]

Hi Dave,

the Etnaviv pull is mostly code cleanups courtesy of Russell King this
time, improving readability of certain parts of the driver a lot.

Notable changes:
- correctness fixes to the GPU cache flushing when switching execution
state and when powering down the GPU
- reduction of time spent in hardirq-off context
- placement improvements to the GPU DMA linear window, allowing the
driver to properly work on i.MX6 systems with more than 2GB of RAM 

Regards,
Lucas

The following changes since commit a90cc3f25065e5e8d5e336c75b04d5882912871f:

  Merge tag 'omapdrm-4.6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next 
(2016-03-05 08:07:58 +1000)

are available in the git repository at:

  git://git.pengutronix.de/git/lst/linux.git drm-etnaviv-next

for you to fetch changes up to 8779aa8f8b7fa397a0abe9e6af3334ea41e15836:

  drm: etnaviv: clean up submit_bo() (2016-03-07 15:37:01 +0100)


Lucas Stach (2):
  drm/etnaviv: move runtime PM balance into retire worker
  drm/etnaviv: move GPU linear window to end of DMA window

Russell King (10):
  drm: etnaviv: extract command ring reservation
  drm: etnaviv: extract replacement of WAIT command
  drm: etnaviv: extract arming of semaphore
  drm: etnaviv: track current execution state
  drm: etnaviv: flush all GPU caches when stopping GPU
  drm: etnaviv: use previous GPU pipe state when pipe switching
  drm: etnaviv: clean up GPU command submission
  drm: etnaviv: improve readability of command insertion to ring buffer
  drm: etnaviv: clean up vram_mapping submission/retire path
  drm: etnaviv: clean up submit_bo()

 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 219 
+++
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|   3 --
 drivers/gpu/drm/etnaviv/etnaviv_gem.c|  54 +++
 drivers/gpu/drm/etnaviv/etnaviv_gem.h|  17 --
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  36 ++---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c|  54 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h|   4 +-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c|   2 +-
 drivers/gpu/drm/etnaviv/state_3d.xml.h   |   9 
 9 files changed, 239 insertions(+), 159 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/state_3d.xml.h

boot hang with vmwgfx on 4.5-rc6

[Thierry Reding]

On Mon, Mar 07, 2016 at 02:51:10PM +0100, Thomas Hellstrom wrote:
> Hi, Daniel,
> 
> It appears you and Thierry are guilty to this:
> 
> d56f57ac969c7818986a0c78025740399e49f3a9
> 
> Could you please revert the vmwgfx-specific parts of that commit before
> 4.5 GA?

Indeed, that hunk looks completely unrelated.

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

[Bug 113861] [radeon] Xorg fatal freeze upon startx

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

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

--- Comment #5 from centuryplague at yandex.com ---
I've attached my dmesg run under 4.1.18 LTS. This was a boot under a regular
user (user doesn't matter, happens with root), and first command was "startx",
which polls eternally, the CTRL+C 500 times, then saved dmesg output.

There is no xorg log produced in any location.

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

[Bug 113861] [radeon] Xorg fatal freeze upon startx

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

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

--- Comment #4 from centuryplague at yandex.com ---
Created attachment 207961
  --> https://bugzilla.kernel.org/attachment.cgi?id=207961=edit
dmesg for radeon xorg lockup upon startx

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

[PATCH] drm/radeon: refactor CIK tiling table initialization

[Josh Poimboeuf]

When compiling the radeon driver on x86_64 with CONFIG_STACK_VALIDATION
enabled, objtool gives the following warnings:

  drivers/gpu/drm/radeon/cik.o: warning: objtool: 
cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup
  drivers/gpu/drm/radeon/cik.o: warning: objtool: 
cik_tiling_mode_table_init()+0x72b: call without frame pointer save/setup
  drivers/gpu/drm/radeon/cik.o: warning: objtool: 
cik_tiling_mode_table_init()+0x464: call without frame pointer save/setup
  ...

These are actually false positive warnings; there are no frame pointer
bugs.  Instead objtool gets confused by the jump tables created by all
the switch statements, combined with some other gcc optimizations.  It
tries to follows all possible code paths, but it fails to realize that
some of the paths aren't possible.  For example:

4c97:   31 c0   xor%eax,%eax
...
4ca2:   89 c1   mov%eax,%ecx
4ca4:   ff 24 cd 00 00 00 00jmpq   *0x0(,%rcx,8) 4ca7: R_X86_64_32S 
 .rodata+0x148

First eax is cleared to zero with the "xor %eax,%eax" instruction.
Later, it moves the value of eax (zero in this case) to ecx, and uses
that value to jump to the first entry in a jump table in .rodata.

Because objtool doesn't have an x86 emulator, it doesn't know that rcx
is zero.  So instead of following a single code path to the first jump
table entry, it follows all possible jump table entry paths in parallel.

Usually such overactive analysis isn't a problem.  In every other jump
table in the kernel, all the jump targets have the same frame pointer
state.  But in this exceedingly rare case, different targets have
different frame pointer states.  Objtool notices that and creates the
false positive warnings.

In theory we could use the STACK_FRAME_NON_STANDARD marker to tell
objtool to skip analysis of the function.  However, that's less than
ideal.

Looking at the cik_tiling_mode_table_init() code, it seems overly
complex with lots of repetition.  So let's simplify it.  All the switch
statements and conditionals can be replaced with much simpler logic by
generalizing the different behaviors and moving the initialization data
into data structures.

The change is a win-win: it's easier to parse for both humans and
machines.  It also reduces the binary size by about 2%:

 text  data bss dec hex filename
   101011 30360   0  131371   2012b cik-before.o
98699 30200   0  128899   1f783 cik-after.o

[ Note: Unfortunately I don't know how to test this code, so it's
  completely untested.  Any help or guidance with ensuring that the
  correct initialization is still being written would be greatly
  appreciated! ]

Reported-by: kbuild test robot 
Signed-off-by: Josh Poimboeuf 
---
Based on linux-next.

 drivers/gpu/drm/radeon/cik.c | 1352 ++
 1 file changed, 325 insertions(+), 1027 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 0600140..1a477e6 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -2327,6 +2327,290 @@ out:
return err;
 }

+#define PIPE_CONFIG_2  0
+#define PIPE_CONFIG_4  1
+#define PIPE_CONFIG_8  2
+#define PIPE_CONFIG_16 3
+
+#define PIPE_CONFIG_4_RBS4 4
+
+#define TILE_SPLIT_ROW_SIZE((unsigned char)-1)
+
+#define NUM_TILE_MODE_STATES   32
+#define NUM_SECONDARY_TILE_MODE_STATES 16
+
+static unsigned char array_modes[][NUM_TILE_MODE_STATES] = {
+   {   /* PIPE_CONFIG_2 */
+   [0 ... 4]   = ARRAY_2D_TILED_THIN1,
+   [5] = ARRAY_1D_TILED_THIN1,
+   [6 ... 7]   = ARRAY_PRT_2D_TILED_THIN1,
+   [8] = ARRAY_LINEAR_ALIGNED,
+   [9] = ARRAY_1D_TILED_THIN1,
+   [10]= ARRAY_2D_TILED_THIN1,
+   [11]= ARRAY_PRT_TILED_THIN1,
+   [12]= ARRAY_PRT_2D_TILED_THIN1,
+   [13]= ARRAY_1D_TILED_THIN1,
+   [14]= ARRAY_2D_TILED_THIN1,
+   [16]= ARRAY_PRT_TILED_THIN1,
+   [17]= ARRAY_PRT_2D_TILED_THIN1,
+   [27]= ARRAY_1D_TILED_THIN1,
+   [28]= ARRAY_PRT_2D_TILED_THIN1,
+   [29]= ARRAY_PRT_TILED_THIN1,
+   [30]= ARRAY_PRT_2D_TILED_THIN1,
+   },
+   {   /* PIPE_CONFIG_4 */
+   [0 ... 4]   = ARRAY_2D_TILED_THIN1,
+   [5] = ARRAY_1D_TILED_THIN1,
+   [6 ... 7]   = ARRAY_PRT_2D_TILED_THIN1,
+   [8] = ARRAY_LINEAR_ALIGNED,
+   [9] = ARRAY_1D_TILED_THIN1,
+   [10]= ARRAY_2D_TILED_THIN1,
+   [11]= ARRAY_PRT_TILED_THIN1,
+   [12]   

[GIT PULL Resend] tilcdc changes for 4.6

[Jyri Sarha]

Hi Dave,

Resend of this pull request:
https://lists.freedesktop.org/archives/dri-devel/2016-February/101685.html

So I am requesting this to be pulled for v4.6.

The patches were reviewed here:
https://lists.freedesktop.org/archives/dri-devel/2016-February/101649.html

Best regards,
Jyri

The following changes since commit 0041ee4d3642f9ad80a479fbe51a4bc7f3cd8294:

   Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into 
drm-next (2016-02-25 10:30:59 +1000)

are available in the git repository at:


   https://github.com/jsarha/linux.git tags/tilcdc-4.6

for you to fetch changes up to d0ec32caef0baa490b419895ef61c8481d49f7cd:

   drm/tilcdc: Use devm_kzalloc() and devm_kcalloc() for private data 
(2016-02-25 16:39:47 +0200)


tilcdc changes for v4.6

Accumulated fixes and improvements from ti-linux-4.1.
* Almost complete rewrite of pagefliping code
* dma-buf support
* pinctrl support
* lot of fixes and cleanups


Darren Etheridge (4):
   drm/tilcdc: rewrite pixel clock calculation
   drm/tilcdc: fix kernel panic on suspend when no hdmi monitor 
connected
   drm/tilcdc: make frame_done interrupt active at all times
   drm/tilcdc: disable the lcd controller/dma engine when suspend 
invoked

Dave Gerlach (1):
   drm/tilcdc: adopt pinctrl support

Grygorii Strashko (1):
   drm/tilcdc: fix build error when !CONFIG_CPU_FREQ

Jyri Sarha (8):
   drm/tilcdc: Implement dma-buf support for tilcdc
   drm/tilcdc: Allocate register storage based on the actual number 
registers
   drm/tilcdc: Fix interrupt enable/disable code for version 2 tilcdc
   drm/tilcdc: Remove the duplicate LCDC_INT_ENABLE_SET_REG in 
registers[]
   drm/tilcdc: Add prints on sync lost and FIFO underrun interrupts
   drm/tilcdc: Disable sync lost interrupt if it fires on every frame
   drm/tilcdc: Initialize crtc->port
   drm/tilcdc: Use devm_kzalloc() and devm_kcalloc() for private data

Tomi Valkeinen (8):
   drm/tilcdc: verify fb pitch
   drm/tilcdc: cleanup runtime PM handling
   drm/tilcdc: disable crtc on unload
   drm/tilcdc: split reset to a separate function
   drm/tilcdc: remove broken error handling
   drm/tilcdc: cleanup irq handling
   drm/tilcdc: Get rid of complex ping-pong mechanism
   drm/tilcdc: Do not update the next frame buffer close to vertical 
blank

  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 313 
++---
  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 130 --
  drivers/gpu/drm/tilcdc/tilcdc_drv.h|   5 +-
  drivers/gpu/drm/tilcdc/tilcdc_panel.c  |  20 +--
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  24 +--
  5 files changed, 300 insertions(+), 192 deletions(-)

Linux 4.4.4 [regression]

[Deucher, Alexander]

> -Original Message-
> From: linus971 at gmail.com [mailto:linus971 at gmail.com] On Behalf Of Linus
> Torvalds
> Sent: Monday, March 07, 2016 11:21 AM
> To: Jörg-Volker Peetz; Dave Airlie; DRI mailing list
> Cc: Greg KH; Linux Kernel Mailing List; Andrew Morton; stable; lwn at lwn.net;
> Jiri Slaby; Deucher, Alexander
> Subject: Re: Linux 4.4.4 [regression]
> 
> On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz 
> wrote:
> >
> > This same problem with X does happen in 4.5-rc7. And removing the line
> > introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 makes
> X go again on
> > my laptop.
> 
> Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainline.
> 
> Dave, Alex: that commit makes Jörg-Volker's HP Pavilion dv7 with
> hybrid graphics (AMD HD 4200 - AMD 5400) unable to run X. No
> suspend/resume in sight, just starting X hangs.
> 
> I'd guess it's the "radeon_switcheroo_set_state()" craziness (based on
> that hybrid graphics thing), but we need to do something since this is
> a regression.
> 
> Just revert for now? Or do you have other suggestions for Jörg-Volker to
> test?

Can you attach your dmesg output?

> 
> Maybe that call to drm_helper_hpd_irq_event() should be purely in the
> real resume path?
> 
> Or maybe there is something that the switcheroo code does that just
> interacts badly with the code in drm_helper_hpd_irq_event()? Deadlock
> on mode_config.mutex or something?
> 
> I suspect we just need to revert, but if somebody who knows the code
> sees some obvious fix, holler quickly, please.

Yes, It's probably something related to switcheroo.  Does the attached patch 
help?

Alex

-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-selectively-call-drm_helper_hpd_irq_event.patch
Type: application/octet-stream
Size: 1087 bytes
Desc: 0001-drm-radeon-selectively-call-drm_helper_hpd_irq_event.patch
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/606d800f/attachment.obj>

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

[Mark yao]

On 2016年03月05日 20:39, Russell King - ARM Linux wrote:
> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
>>> The drm_encoder_cleanup() was missing both from the error path of
>>> dw_hdmi_rockchip_bind().  This caused a crash when slub_debug was
>>> enabled and we ended up deferring probe of HDMI at boot.
>>>
>>> This call isn't needed from unbind() because if dw_hdmi_bind() returns
>>> no error then it takes over the job of freeing the encoder (in
>>> dw_hdmi_unbind).
>>>
>>> Signed-off-by: Douglas Anderson 
>>> ---
>> Does dw_hdmi-imx need a similar change?  I wonder if it would be cleaner
>> to push this into dw_hdmi_bind() if it affects all of the platforms..
> I don't think moving it there would make sense - keep the initialisation
> and cleanup together in the same file so that it's contained together.
>

I don't like this patch too, initialisation and cleanup not in the same 
file looks bad,

How about:

drivers/gpu/drm/bridge/dw-hdmi.c
void dw_hdmi_unbind(struct device *dev, struct device *master, void *data)
 hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);

hdmi->connector.funcs->destroy(>connector);
-   hdmi->encoder->funcs->destroy(hdmi->encoder);

drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,

-   return dw_hdmi_bind(dev, master, data, encoder, iores, irq, 
plat_data);
+   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, 
plat_data);
+   if (ret)
+   drm_encoder_cleanup(encoder);
+
+   return ret;
  }

  static void dw_hdmi_rockchip_unbind(struct device *dev, struct device 
*master,
 void *data)
  {
+   drm_encoder_cleanup(...);
 return dw_hdmi_unbind(dev, master, data);
  }

Thanks.

-- 
ï¼­ark Yao

[Bug 113861] [radeon] Xorg fatal freeze upon startx

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #3 from Alex Deucher  ---
Please attach your dmesg output and xorg log.

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

[PATCH] drm: Check for connector->state NULL in drm_atomic_add_affected_connectors

[Doug Anderson]

Hi,

On Mon, Mar 7, 2016 at 4:05 PM, Doug Anderson  wrote:
> Daniel,
>
> On Sun, Mar 6, 2016 at 8:29 AM, Daniel Vetter  wrote:
>> On Fri, Mar 04, 2016 at 03:43:53PM -0800, Douglas Anderson wrote:
>>> On a system I'm doing development on I found a crash.  The crawl looked
>>> like:
>>>
>>>   PC is at drm_atomic_add_affected_connectors+0x98/0xe8
>>>   ...
>>>   drm_atomic_add_affected_connectors from 
>>> __drm_atomic_helper_set_config+0x218/0x344
>>>   __drm_atomic_helper_set_config from restore_fbdev_mode+0x108/0x250
>>>   restore_fbdev_mode from 
>>> drm_fb_helper_restore_fbdev_mode_unlocked+0x3c/0x80
>>>   drm_fb_helper_restore_fbdev_mode_unlocked from 
>>> rockchip_drm_lastclose+0x1c/0x20
>>>   rockchip_drm_lastclose from drm_lastclose+0x4c/0x104
>>>   drm_lastclose from drm_release+0x424/0x47c
>>>   drm_release from __fput+0xf8/0x1d4
>>>   __fput from fput+0x18/0x1c
>>>   fput from task_work_run+0xa8/0xbc
>>>   task_work_run from do_exit+0x448/0x91c
>>>   do_exit from do_group_exit+0x5c/0xcc
>>>   do_group_exit from get_signal+0x4dc/0x57c
>>>   get_signal from do_signal+0x9c/0x3b4
>>>   do_signal from do_work_pending+0x60/0xb8
>>>   do_work_pending from slow_work_pending+0xc/0x20
>>>
>>> I found that I could fix the crash by checking connector->state against
>>> NULL.  This isn't code I'm familiar with and I didn't dig too deep, so
>>> I'd appreciate any opinions about whether this is a sane thing to do.
>>> Note that I don't actually have graphics up on my system at the moment,
>>> so perhaps this is all just a symptom of the strange state I'm in.
>>>
>>> Signed-off-by: Douglas Anderson 
>>
>> This is a driver bug - under atomic the assumption is that there is
>> _always_ a current software state. Most driver set up the initial
>> "everything off" state in the ->reset functions.
>
> Ah, I see what the problem is.  It looks like the main Rockchip
> subsystem moved to atomic but the patch to support that in dw_hdmi
> never landed.  If I pick 
> then my crash goes away.  :)
>
> In case it's not obvious, please consider $SUBJECT patch abandoned.  Thanks!

Argh.  ...or the needed patch landed but I didn't pick it back in my
backport.  Even dumber.  :(

-Doug

[PATCH] drm: Check for connector->state NULL in drm_atomic_add_affected_connectors

[Doug Anderson]

Daniel,

On Sun, Mar 6, 2016 at 8:29 AM, Daniel Vetter  wrote:
> On Fri, Mar 04, 2016 at 03:43:53PM -0800, Douglas Anderson wrote:
>> On a system I'm doing development on I found a crash.  The crawl looked
>> like:
>>
>>   PC is at drm_atomic_add_affected_connectors+0x98/0xe8
>>   ...
>>   drm_atomic_add_affected_connectors from 
>> __drm_atomic_helper_set_config+0x218/0x344
>>   __drm_atomic_helper_set_config from restore_fbdev_mode+0x108/0x250
>>   restore_fbdev_mode from drm_fb_helper_restore_fbdev_mode_unlocked+0x3c/0x80
>>   drm_fb_helper_restore_fbdev_mode_unlocked from 
>> rockchip_drm_lastclose+0x1c/0x20
>>   rockchip_drm_lastclose from drm_lastclose+0x4c/0x104
>>   drm_lastclose from drm_release+0x424/0x47c
>>   drm_release from __fput+0xf8/0x1d4
>>   __fput from fput+0x18/0x1c
>>   fput from task_work_run+0xa8/0xbc
>>   task_work_run from do_exit+0x448/0x91c
>>   do_exit from do_group_exit+0x5c/0xcc
>>   do_group_exit from get_signal+0x4dc/0x57c
>>   get_signal from do_signal+0x9c/0x3b4
>>   do_signal from do_work_pending+0x60/0xb8
>>   do_work_pending from slow_work_pending+0xc/0x20
>>
>> I found that I could fix the crash by checking connector->state against
>> NULL.  This isn't code I'm familiar with and I didn't dig too deep, so
>> I'd appreciate any opinions about whether this is a sane thing to do.
>> Note that I don't actually have graphics up on my system at the moment,
>> so perhaps this is all just a symptom of the strange state I'm in.
>>
>> Signed-off-by: Douglas Anderson 
>
> This is a driver bug - under atomic the assumption is that there is
> _always_ a current software state. Most driver set up the initial
> "everything off" state in the ->reset functions.

Ah, I see what the problem is.  It looks like the main Rockchip
subsystem moved to atomic but the patch to support that in dw_hdmi
never landed.  If I pick 
then my crash goes away.  :)

In case it's not obvious, please consider $SUBJECT patch abandoned.  Thanks!

-Doug

Kernel WARNING via bochsdrmfb mmap

[Jiri Slaby]

On 03/07/2016, 03:30 PM, Takashi Iwai wrote:
> Hi,
> 
> Jiri Slaby reported a kernel WARNING triggered by syzkaller.  It can
> be reliably reproduced via fbdev mmap access on bochs drm.  The
> warning looks like below:
> 
> WARNING: CPU: 3 PID: 29356 at ../drivers/gpu/drm/ttm/ttm_bo_vm.c:265 
> ttm_bo_vm_open+0x11a/0x180 [ttm]()

BTW running the reproducer on my box gives:
x86/PAT: ac:501 freeing invalid memtype [mem 0xe083d000-0xe083dfff]

and not the warning.

thanks,
-- 
js
suse labs

[PATCH 05/16] drm/gma: removed optional dummy crtc mode_fixup function.

[Patrik Jakobsson]

On Tue, Feb 16, 2016 at 3:17 PM, Carlos Palminha
 wrote:
> This patch set nukes all the dummy crtc mode_fixup implementations.
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha 

You should try to avoid mixing code style fixes with functional
changes but in case of gma500 it's hard to resist. No need to change
this.

This might already have been merged but if not:

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/gma500/cdv_intel_display.c   | 13 ++---
>  drivers/gpu/drm/gma500/gma_display.c |  7 ---
>  drivers/gpu/drm/gma500/gma_display.h |  3 ---
>  drivers/gpu/drm/gma500/mdfld_intel_display.c |  2 --
>  drivers/gpu/drm/gma500/oaktrail_crtc.c   |  1 -
>  drivers/gpu/drm/gma500/psb_intel_display.c   |  1 -
>  6 files changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
> b/drivers/gpu/drm/gma500/cdv_intel_display.c
> index 6126546..17db4b4 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_display.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
> @@ -116,7 +116,7 @@ static const struct gma_limit_t cdv_intel_limits[] = {
>  .p1 = {.min = 1, .max = 10},
>  .p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 10},
>  .find_pll = cdv_intel_find_dp_pll,
> -}
> +   }
>  };
>
>  #define _wait_for(COND, MS, W) ({ \
> @@ -245,7 +245,7 @@ cdv_dpll_set_clock_cdv(struct drm_device *dev, struct 
> drm_crtc *crtc,
> /* We don't know what the other fields of these regs are, so
>  * leave them in place.
>  */
> -   /*
> +   /*
>  * The BIT 14:13 of 0x8010/0x8030 is used to select the ref clk
>  * for the pipe A/B. Display spec 1.06 has wrong definition.
>  * Correct definition is like below:
> @@ -256,7 +256,7 @@ cdv_dpll_set_clock_cdv(struct drm_device *dev, struct 
> drm_crtc *crtc,
>  *
>  * if DPLLA sets 01 and DPLLB sets 02, both use clk from DPLLA
>  *
> -*/
> +*/
> ret = cdv_sb_read(dev, ref_sfr, _value);
> if (ret)
> return ret;
> @@ -646,7 +646,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
>  * for DP/eDP. When using SSC clock, the ref clk is 
> 100MHz.Otherwise
>  * it will be 27MHz. From the VBIOS code it seems that the 
> pipe A choose
>  * 27MHz for DP/eDP while the Pipe B chooses the 100MHz.
> -*/
> +*/
> if (pipe == 0)
> refclk = 27000;
> else
> @@ -659,7 +659,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
> }
>
> drm_mode_debug_printmodeline(adjusted_mode);
> -
> +
> limit = gma_crtc->clock_funcs->limit(crtc, refclk);
>
> ok = limit->find_pll(limit, crtc, adjusted_mode->clock, refclk,
> @@ -721,7 +721,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
> pipeconf |= PIPE_6BPC;
> } else
> pipeconf |= PIPE_8BPC;
> -
> +
> /* Set up the display plane register */
> dspcntr = DISPPLANE_GAMMA_ENABLE;
>
> @@ -974,7 +974,6 @@ struct drm_display_mode *cdv_intel_crtc_mode_get(struct 
> drm_device *dev,
>
>  const struct drm_crtc_helper_funcs cdv_intel_helper_funcs = {
> .dpms = gma_crtc_dpms,
> -   .mode_fixup = gma_crtc_mode_fixup,
> .mode_set = cdv_intel_crtc_mode_set,
> .mode_set_base = gma_pipe_set_base,
> .prepare = gma_crtc_prepare,
> diff --git a/drivers/gpu/drm/gma500/gma_display.c 
> b/drivers/gpu/drm/gma500/gma_display.c
> index ff17af4..d6a5c77 100644
> --- a/drivers/gpu/drm/gma500/gma_display.c
> +++ b/drivers/gpu/drm/gma500/gma_display.c
> @@ -485,13 +485,6 @@ bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
> return true;
>  }
>
> -bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
> -const struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode)
> -{
> -   return true;
> -}
> -
>  void gma_crtc_prepare(struct drm_crtc *crtc)
>  {
> const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> diff --git a/drivers/gpu/drm/gma500/gma_display.h 
> b/drivers/gpu/drm/gma500/gma_display.h
> index ed569d8..fc64241 100644
> --- a/drivers/gpu/drm/gma500/gma_display.h
> +++ b/drivers/gpu/drm/gma500/gma_display.h
> @@ -75,9 +75,6 @@ extern void gma_crtc_load_lut(struct drm_crtc *crtc);
>  extern void gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
>u16 *blue, u32 start, u32 size);
>  extern void gma_crtc_dpms(struct drm_crtc *crtc, int mode);
> -extern bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
> -   const struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode);
>  extern void 

Kernel WARNING via bochsdrmfb mmap

[Takashi Iwai]

Hi,

Jiri Slaby reported a kernel WARNING triggered by syzkaller.  It can
be reliably reproduced via fbdev mmap access on bochs drm.  The
warning looks like below:

WARNING: CPU: 3 PID: 29356 at ../drivers/gpu/drm/ttm/ttm_bo_vm.c:265 
ttm_bo_vm_open+0x11a/0x180 [ttm]()
Modules linked in: ...
Supported: Yes
CPU: 3 PID: 29356 Comm: syz-executor Tainted: GE  
4.4.3-0-default #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
 0003 880036cbfb50 819eae91 
 880035294000 a0a46d60 0009 880036cbfb90
 8116face a0a34e5a a0a46d60 0109
Call Trace:
 [] ? dump_stack+0xb3/0x112
 [] ? warn_slowpath_common+0xde/0x140
 [] ? ttm_bo_vm_open+0x11a/0x180 [ttm]
 [] ? ttm_bo_vm_fault+0xe70/0xe70 [ttm]
 [] ? warn_slowpath_null+0x2e/0x40
 [] ? ttm_bo_vm_open+0x11a/0x180 [ttm]
 [] ? __split_vma.isra.30+0x3ed/0x7f0
 [] ? do_munmap+0xd14/0x1010
 [] ? __lock_acquire+0xb3d/0x49d0
 [] ? mmap_region+0x1d5/0x11d0
 [] ? cap_mmap_addr+0x46/0x110
 [] ? do_mmap+0x758/0x990
 [] ? vm_mmap_pgoff+0x164/0x1b0
 [] ? task_of_stack+0x240/0x240
 [] ? SyS_mmap_pgoff+0xcd/0x590
 [] ? vm_stat_account+0x130/0x130
 [] ? security_file_ioctl+0x91/0xc0
 [] ? lockdep_sys_exit_thunk+0x12/0x14
 [] ? SyS_mmap+0x1b/0x30
 [] ? entry_SYSCALL_64_fastpath+0x12/0x76

The bug was confirmed to happen on the latest vanilla 4.5-rc6, too.
The reproducer code is attached below.

Judging from the code, it comes from the fact that
vma->vm_file->f_mapping via fbdev access isn't changed to bodev's
one.  In the case of /dev/dri/*, f_mapping is replaced in drm_open().
But, fbdev open doesn't change f_mapping, and its callback doesn't
take the file pointer, so there is no way to fiddle with it there,
either.

What's the preferred way to fix this?  I can think of several ways,
e.g.
- adding f_mapping pointer field in struct fb_info
- passing the file pointer in fbdev open callback so that f_mapping
  can be corrected
- adjusting f_mapping in vm_open dynamically (is it safe?)
or
- drop WARN_ON() :)


thanks,

Takashi

---
#include 
#include 
#include 
#include 

#include 
#include 
#include 

int main(void)
{
void *addr;

int fd = open("/dev/fb0", O_RDONLY);
if (fd < 0)
err(1, "open");

addr = mmap(0, 8192, PROT_READ, MAP_SHARED, fd, 0);
if (addr == MAP_FAILED)
err(1, "1st mmap");

if (mmap(addr, 4096, PROT_READ, MAP_SHARED | MAP_FIXED | MAP_ANONYMOUS, 
-1, 0) == MAP_FAILED)
err(1, "2nd mmap");

return 0;
}

boot hang with vmwgfx on 4.5-rc6

[Thomas Hellstrom]

Hi, Daniel,

It appears you and Thierry are guilty to this:

d56f57ac969c7818986a0c78025740399e49f3a9

Could you please revert the vmwgfx-specific parts of that commit before
4.5 GA?

Thanks,
Thomas



On 03/04/2016 11:39 PM, Thomas Hellstrom wrote:
> Hi!
>
> Thanks for reporting. It appears that on hardware version 9, we get a
> NULL pointer dereference
> on kernel 4.5.
>
> [   15.298499] BUG: unable to handle kernel NULL pointer dereference
> at   (null)
> [   15.301027] IP: [<  (null)>]   (null)
> [   15.302590] PGD 0
> [   15.303276] Oops: 0010 [#1] SMP
> [   15.304385] Modules linked in: xt_conntrack ebtable_filter
> ebtable_nat ebtable_broute bridge stp llc ebtables ip6table_security
> ip6table_raw ip6table_mangle ip6table_nat nf_conntrack_ipv6
> nf_defrag_ipv6 nf_nat_ipv6 ip6table_filter ip6_tables iptable_security
> iptable_raw iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 nf_nat nf_conntrack vmw_vsock_vmci_transport vsock
> snd_seq_midi bnep snd_seq_midi_event btusb btrtl snd_ens1371 gameport
> btbcm snd_ac97_codec btintel ppdev ac97_bus snd_seq coretemp
> crct10dif_pclmul crc32_pclmul bluetooth snd_pcm crc32c_intel vmw_balloon
> ghash_clmulni_intel snd_rawmidi snd_timer snd_seq_device snd rfkill
> soundcore vmw_vmci shpchp i2c_piix4 nfit parport_pc parport acpi_cpufreq
> nfsd auth_rpcgss nfs_acl lockd grace sunrpc vmwgfx serio_raw
> drm_kms_helper vmw_pvscsi vmxnet3 ttm drm ata_generic pata_acpi
> [   15.330004] CPU: 1 PID: 1075 Comm: gnome-shell Not tainted 4.5.0-rc6 #1
> [   15.332000] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
> Desktop Reference Platform, BIOS 6.00 07/02/2015
> [   15.335179] task: 880077394b00 ti: 8800773a8000 task.ti:
> 8800773a8000
> [   15.337411] RIP: 0010:[<>]  [< 
> (null)>]   (null)
> [   15.339729] RSP: 0018:8800773abc50  EFLAGS: 00010246
> [   15.341335] RAX: a00ed640 RBX: 880036171000 RCX:
> 880036173770
> [   15.343470] RDX: 2000 RSI: 2000 RDI:
> 8800361734b8
> [   15.345605] RBP: 8800773abd18 R08:  R09:
> 
> [   15.347798] R10:  R11:  R12:
> 8800361734e0
> [   15.349929] R13: 880036171000 R14: 8800773abd60 R15:
> fffe
> [   15.352096] FS:  7fb347faca80() GS:88007c64()
> knlGS:
> [   15.354513] CS:  0010 DS:  ES:  CR0: 80050033
> [   15.356230] CR2:  CR3: 7739f000 CR4:
> 001406e0
> [   15.358427] Stack:
> [   15.359092]  a0024535 8800773abc68 811196cd
> 880036173764
> [   15.361477]  880036173770 0001 880036171410
> 8801
> [   15.364091]  880079f38000  812059bd
> 
> [   15.366488] Call Trace:
> [   15.367278]  [] ? drm_mode_getconnector+0x375/0x400
> [drm]
> [   15.369515]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
> [   15.371537]  [] drm_ioctl+0x152/0x560 [drm]
> [   15.373295]  [] ? drm_mode_getcrtc+0x150/0x150 [drm]
> [   15.375268]  [] vmw_generic_ioctl+0x17d/0x280 [vmwgfx]
> [   15.377277]  [] ? drm_getmap+0xe0/0xe0 [drm]
> [   15.379044]  [] vmw_unlocked_ioctl+0x15/0x20 [vmwgfx]
> [   15.381043]  [] do_vfs_ioctl+0xa2/0x690
> [   15.382684]  [] ? __fget+0x11f/0x200
> [   15.384249]  [] ? __fget+0x5/0x200
> [   15.385760]  [] SyS_ioctl+0x79/0x90
> [   15.387296]  [] entry_SYSCALL_64_fastpath+0x12/0x76
> [   15.389246] Code:  Bad RIP value.
> [   15.390375] RIP  [<  (null)>]   (null)
> [   15.391992]  RSP 
> [   15.393081] CR2: 
> [   15.394174] ---[ end trace f9f3f138ca13da13 ]---
>
> On 02/29/2016 10:38 PM, Sebastian Herbszt wrote:
>> Hello,
>>
>> I get a boot hang with vmwgfx on 4.5-rc6 (4.5.0-rc6-1.gb239884-default from
>> openSUSE). This happens on VMware Player 5.0.2.
>> Same VM works fine with kernel 4.4 but on 4.5-rc6 it hangs with
>>
>> [drm] Initialized vmwgfx 2.9.0 20150810 for :00:0f.0 on minor 0
>>
>> I am able to boot the system with "nomodeset".
>>
>> Sebastian
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4.2.y-ckt 170/273] drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)

[Kamal Mostafa]

4.2.8-ckt5 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Mario Kleiner 

commit bb74fc1bf3072bd3ab4ed5f43afd287a63baf2d7 upstream.

drm_vblank_offdelay can have three different types of values:

< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
that way via dev->vblank_disable_immediate. Otherwise it is
a disable timeout in msecs.

This got broken in Linux 3.18+ for the implementation of
drm_vblank_on. If the user specified a value of zero which should
always reenable vblank irqs in this function, a kms driver could
override the users choice by setting vblank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.

v2: Only reenable vblank if there are clients left or the user
requested to "never disable vblanks" via offdelay 0. Enabling
vblanks even in the "delayed disable" case (offdelay > 0) was
specifically added by Ville in commit cd19e52aee922
("drm: Kick start vblank interrupts at drm_vblank_on()"),
but after discussion it turns out that this was done by accident.

Citing Ville: "I think it just ended up as a mess due to changing
some of the semantics of offdelay<0 vs. offdelay==0 vs.
disable_immediate during the review of the series. So yeah, given
how drm_vblank_put() works now, I'd just make this check for
offdelay==0."

Signed-off-by: Mario Kleiner 
Reviewed-by: Daniel Vetter 

Cc: michel at daenzer.net
Cc: vbabka at suse.cz
Cc: ville.syrjala at linux.intel.com
Cc: daniel.vetter at ffwll.ch
Cc: dri-devel at lists.freedesktop.org
Cc: alexander.deucher at amd.com
Cc: christian.koenig at amd.com
Signed-off-by: Dave Airlie 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/drm_irq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index b50fa0a..6447b48 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1338,8 +1338,7 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
 * re-enable interrupts if there are users left, or the
 * user wishes vblank interrupts to be enabled all the time.
 */
-   if (atomic_read(>refcount) != 0 ||
-   (!dev->vblank_disable_immediate && drm_vblank_offdelay == 0))
+   if (atomic_read(>refcount) != 0 || drm_vblank_offdelay == 0)
WARN_ON(drm_vblank_enable(dev, crtc));
spin_unlock_irqrestore(>vbl_lock, irqflags);
 }
-- 
2.7.0

[4.2.y-ckt stable] Patch "drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)" has been added to the 4.2.y-ckt tree

[Kamal Mostafa]

This is a note to let you know that I have just added a patch titled

drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)

to the linux-4.2.y-queue branch of the 4.2.y-ckt extended stable tree 
which can be found at:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-4.2.y-queue

This patch is scheduled to be released in version 4.2.8-ckt5.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 4.2.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Kamal

---8<

>From 5e9a7dec7acb148f29a0b24f66c6e22caa1aa592 Mon Sep 17 00:00:00 2001
From: Mario Kleiner 
Date: Fri, 12 Feb 2016 20:30:30 +0100
Subject: drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)

commit bb74fc1bf3072bd3ab4ed5f43afd287a63baf2d7 upstream.

drm_vblank_offdelay can have three different types of values:

< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
that way via dev->vblank_disable_immediate. Otherwise it is
a disable timeout in msecs.

This got broken in Linux 3.18+ for the implementation of
drm_vblank_on. If the user specified a value of zero which should
always reenable vblank irqs in this function, a kms driver could
override the users choice by setting vblank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.

v2: Only reenable vblank if there are clients left or the user
requested to "never disable vblanks" via offdelay 0. Enabling
vblanks even in the "delayed disable" case (offdelay > 0) was
specifically added by Ville in commit cd19e52aee922
("drm: Kick start vblank interrupts at drm_vblank_on()"),
but after discussion it turns out that this was done by accident.

Citing Ville: "I think it just ended up as a mess due to changing
some of the semantics of offdelay<0 vs. offdelay==0 vs.
disable_immediate during the review of the series. So yeah, given
how drm_vblank_put() works now, I'd just make this check for
offdelay==0."

Signed-off-by: Mario Kleiner 
Reviewed-by: Daniel Vetter 

Cc: michel at daenzer.net
Cc: vbabka at suse.cz
Cc: ville.syrjala at linux.intel.com
Cc: daniel.vetter at ffwll.ch
Cc: dri-devel at lists.freedesktop.org
Cc: alexander.deucher at amd.com
Cc: christian.koenig at amd.com
Signed-off-by: Dave Airlie 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/drm_irq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index b50fa0a..6447b48 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1338,8 +1338,7 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
 * re-enable interrupts if there are users left, or the
 * user wishes vblank interrupts to be enabled all the time.
 */
-   if (atomic_read(>refcount) != 0 ||
-   (!dev->vblank_disable_immediate && drm_vblank_offdelay == 0))
+   if (atomic_read(>refcount) != 0 || drm_vblank_offdelay == 0)
WARN_ON(drm_vblank_enable(dev, crtc));
spin_unlock_irqrestore(>vbl_lock, irqflags);
 }
--
2.7.0

[Bug 113891] [radeon] Display jitter

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

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

Jean Delvare  changed:

   What|Removed |Added

 Regression|No  |Yes

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

[Bug 113891] New: [radeon] Display jitter

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

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

Bug ID: 113891
   Summary: [radeon] Display jitter
   Product: Drivers
   Version: 2.5
Kernel Version: 4.4.4
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: jdelvare at suse.de
Regression: No

Since updating to kernel v4.4.4 (from v4.4.3), I get vertical jitter on my
display with almost every boot. The picture moves up and down with black
horizontal stripes. This makes the system pretty much unusable.

I bisected it to the following commit:

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.4.y=a83b349814dee660caff0a40a22ac2f166c94a8b

drm/radeon/pm: adjust display configuration after powerstate

I am now running v4.4.4 with this commit reverted and so far so good. My
hardware:

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Turks XT [Radeon HD 6670/7670] [1002:6758] (Sapphire HD 6670)

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

[Bug 113341] GPU Lockup on AMD Kaveri

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

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

--- Comment #7 from Bernd Steinhauser  ---
I tried to build LLVM/clang scm, but it failed (have to check why and if I can
get around that).

I've had several freezes over the last few weeks (most of them when I bisected
that other bug mentioned above (so could be unrelated), but only a few after
staying on 4.4.x), but this one was the only one I could relate to a specific
event, starting an application (thunderbird here).
The other ones seemed to happen out of nowhere, so it could be that it was just
coincidence that it happened when I started that application.

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

[PATCH v2 5/5] drm/imx: dw_hdmi: Don't call platform_set_drvdata()

[Douglas Anderson]

The IMX dw_hdmi driver just called platform_set_drvdata() to get
your hopes up that maybe, somehow, you'd be able to retrieve the 'struct
imx_hdmi' from a pointer to the 'struct device'.  You can't.  When
we call dw_hdmi_bind() the main driver calls dev_set_drvdata(), which
clobbers our setting.

Let's just remove the platform_set_drvdata() to avoid dashing people's
hopes.

Signed-off-by: Douglas Anderson 
---
Changes in v2:
- Don't call platform_set_drvdata() new for v2.

 drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index c69c3142819c..a24631fdf4ad 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -225,8 +225,6 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
if (!iores)
return -ENXIO;

-   platform_set_drvdata(pdev, hdmi);
-
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
/*
 * If we failed to find the CRTC(s) which this encoder is
-- 
2.7.0.rc3.207.g0ac5344

[PATCH v2 4/5] drm/rockchip: dw_hdmi: Don't call platform_set_drvdata()

[Douglas Anderson]

The Rockchip dw_hdmi driver just called platform_set_drvdata() to get
your hopes up that maybe, somehow, you'd be able to retrieve the 'struct
rockchip_hdmi' from a pointer to the 'struct device'.  You can't.  When
we call dw_hdmi_bind() the main driver calls dev_set_drvdata(), which
clobbers our setting.

Let's just remove the platform_set_drvdata() to avoid dashing people's
hopes.

Signed-off-by: Douglas Anderson 
---
Changes in v2:
- Don't call platform_set_drvdata() new for v2.

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 88776aba984e..d5cfef75fc80 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -271,8 +271,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
if (!iores)
return -ENXIO;

-   platform_set_drvdata(pdev, hdmi);
-
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
/*
 * If we failed to find the CRTC(s) which this encoder is
-- 
2.7.0.rc3.207.g0ac5344

[PATCH v2 3/5] drm/rockchip: vop: Fix vop crtc cleanup

[Douglas Anderson]

This fixes a few problems in the vop crtc cleanup (handling error
paths and cleanup upon exit):

* The vop_create_crtc() error path had an unsafe version of the
  iterator used for iterating over all planes (though it was
  destroying planes in the iterator so should have used the safe
  version)

* vop_destroy_crtc() - wasn't calling vop_plane_destroy(), which made
  slub_debug unhappy, at least if we ended up running this due to a
  deferred probe.

* In vop_create_crtc() if we were missing the "port" device tree node
  we would fail but not return an error (found by code inspection).

Fix these problems.

Signed-off-by: Douglas Anderson 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fd370548d7d7..f86f797f10fd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1108,7 +1108,7 @@ static int vop_create_crtc(struct vop *vop)
const struct vop_data *vop_data = vop->data;
struct device *dev = vop->dev;
struct drm_device *drm_dev = vop->drm_dev;
-   struct drm_plane *primary = NULL, *cursor = NULL, *plane;
+   struct drm_plane *primary = NULL, *cursor = NULL, *plane, *tmp;
struct drm_crtc *crtc = >crtc;
struct device_node *port;
int ret;
@@ -1148,7 +1148,7 @@ static int vop_create_crtc(struct vop *vop)
ret = drm_crtc_init_with_planes(drm_dev, crtc, primary, cursor,
_crtc_funcs, NULL);
if (ret)
-   return ret;
+   goto err_cleanup_planes;

drm_crtc_helper_add(crtc, _crtc_helper_funcs);

@@ -1181,6 +1181,7 @@ static int vop_create_crtc(struct vop *vop)
if (!port) {
DRM_ERROR("no port node found in %s\n",
  dev->of_node->full_name);
+   ret = -ENOENT;
goto err_cleanup_crtc;
}

@@ -1194,7 +1195,8 @@ static int vop_create_crtc(struct vop *vop)
 err_cleanup_crtc:
drm_crtc_cleanup(crtc);
 err_cleanup_planes:
-   list_for_each_entry(plane, _dev->mode_config.plane_list, head)
+   list_for_each_entry_safe(plane, tmp, _dev->mode_config.plane_list,
+head)
drm_plane_cleanup(plane);
return ret;
 }
@@ -1202,9 +1204,28 @@ err_cleanup_planes:
 static void vop_destroy_crtc(struct vop *vop)
 {
struct drm_crtc *crtc = >crtc;
+   struct drm_device *drm_dev = vop->drm_dev;
+   struct drm_plane *plane, *tmp;

rockchip_unregister_crtc_funcs(crtc);
of_node_put(crtc->port);
+
+   /*
+* We need to cleanup the planes now.  Why?
+*
+* The planes are ">win[i].base".  That means the memory is
+* all part of the big "struct vop" chunk of memory.  That memory
+* was devm allocated and associated with this component.  We need to
+* free it ourselves before vop_unbind() finishes.
+*/
+   list_for_each_entry_safe(plane, tmp, _dev->mode_config.plane_list,
+head)
+   vop_plane_destroy(plane);
+
+   /*
+* Destroy CRTC after vop_plane_destroy() since vop_disable_plane()
+* references the CRTC.
+*/
drm_crtc_cleanup(crtc);
 }

-- 
2.7.0.rc3.207.g0ac5344

[PATCH v2 2/5] drm/imx: dw_hdmi: Call drm_encoder_cleanup() in error path

[Douglas Anderson]

The drm_encoder_cleanup() was missing both from the error path of
dw_hdmi_imx_bind().  This caused a crash when slub_debug was
enabled and we ended up deferring probe of HDMI at boot.

This call isn't needed from unbind() because if dw_hdmi_bind() returns
no error then it takes over the job of freeing the encoder (in
dw_hdmi_unbind).

Signed-off-by: Douglas Anderson 
---
Changes in v2:
- IMX patch new in v2

 drivers/gpu/drm/imx/dw_hdmi-imx.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 2a95d10e9d92..c69c3142819c 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -245,7 +245,16 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);

-   return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+
+   /*
+* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
+* which would have called the encoder cleanup.  Do it manually.
+*/
+   if (ret)
+   drm_encoder_cleanup(encoder);
+
+   return ret;
 }

 static void dw_hdmi_imx_unbind(struct device *dev, struct device *master,
-- 
2.7.0.rc3.207.g0ac5344

[PATCH v2 1/5] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

[Douglas Anderson]

The drm_encoder_cleanup() was missing both from the error path of
dw_hdmi_rockchip_bind().  This caused a crash when slub_debug was
enabled and we ended up deferring probe of HDMI at boot.

This call isn't needed from unbind() because if dw_hdmi_bind() returns
no error then it takes over the job of freeing the encoder (in
dw_hdmi_unbind).

Signed-off-by: Douglas Anderson 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 3d3cf2f8891e..88776aba984e 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -293,7 +293,16 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
drm_encoder_init(drm, encoder, _hdmi_rockchip_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);

-   return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+
+   /*
+* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
+* which would have called the encoder cleanup.  Do it manually.
+*/
+   if (ret)
+   drm_encoder_cleanup(encoder);
+
+   return ret;
 }

 static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
-- 
2.7.0.rc3.207.g0ac5344

[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

[Martin Kepplinger]

Am 2016-03-03 um 16:05 schrieb Takashi Iwai:
> On Mon, 29 Feb 2016 15:39:53 +0100,
> Jani Nikula wrote:
>>
>> On Mon, 29 Feb 2016, Martin Kepplinger  wrote:
>>> Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
 Sorry, Cc to Jani was missing mistakenly.

 Please check this.  It's a regression in 4.5-rc.


 thanks,

 Takashi

>>>
>>> I can confirm that with -rc6 nothing changed and this fixes audio over
>>> HDMI for me. I added David Airlie and dri-devel to CC aswell and hope
>>> that this can go in for 4.5 in the last minute.
>>
>> I'll pick this up when we get the CI results. (This had fallen between
>> the cracks...)
> 
> As far as looking at linux-next, this one still seems remaining in the
> crevasse...
> 

This still isn't merged but still fixes a serious regression in v4.5.
What's going on?

thanks
martin

> 
> thanks,
> 
> Takashi
> 
>>
>> BR,
>> Jani.
>>
>>
>>
>>>
>>> thanks
>>> martin
>>>
>>>
 On Wed, 24 Feb 2016 15:35:22 +0100,
 Takashi Iwai wrote:
>
> The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between
> port and intel_encoder] introduced a reverse mapping to retrieve
> intel_dig_port object from the port number.  The code assumed that the
> port vs intel_dig_port are 1:1 mapping.  But in reality, this was a
> too naive assumption.
>
> As Martin reported about the missing HDMI audio on his SNB machine,
> pre-HSW chips may have multiple intel_dig_port objects corresponding
> to the same port.  Since we assign the mapping statically at the init
> time and the multiple objects override the map, it may not match with
> the actually enabled output.
>
> This patch tries to address the regression above.  The reverse mapping
> is provided basically only for the audio callbacks, so now we set /
> clear the mapping dynamically at enabling and disabling HDMI/DP audio,
> so that we can always track the latest and correct object
> corresponding to the given port.
>
> Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and 
> intel_encoder')
> Reported-and-tested-by: Martin Kepplinger 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 3 +++
>  drivers/gpu/drm/i915/intel_ddi.c   | 1 -
>  drivers/gpu/drm/i915/intel_dp.c| 1 -
>  drivers/gpu/drm/i915/intel_hdmi.c  | 2 --
>  4 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 31f6d212fb1b..30f921421b0c 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -527,6 +527,8 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>  
>   mutex_lock(_priv->av_mutex);
>   intel_dig_port->audio_connector = connector;
> + /* referred in audio callbacks */
> + dev_priv->dig_port_map[port] = intel_encoder;
>   mutex_unlock(_priv->av_mutex);
>  
>   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> @@ -554,6 +556,7 @@ void intel_audio_codec_disable(struct intel_encoder 
> *intel_encoder)
>  
>   mutex_lock(_priv->av_mutex);
>   intel_dig_port->audio_connector = NULL;
> + dev_priv->dig_port_map[port] = NULL;
>   mutex_unlock(_priv->av_mutex);
>  
>   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 54a165b9c92d..a50fc452d5f1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3312,7 +3312,6 @@ void intel_ddi_init(struct drm_device *dev, enum 
> port port)
>   intel_encoder->get_config = intel_ddi_get_config;
>  
>   intel_dig_port->port = port;
> - dev_priv->dig_port_map[port] = intel_encoder;
>   intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
> (DDI_BUF_PORT_REVERSAL |
>  DDI_A_4_LANES);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> b/drivers/gpu/drm/i915/intel_dp.c
> index 1bbd67b046da..acf918728492 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6035,7 +6035,6 @@ intel_dp_init(struct drm_device *dev,
>   }
>  
>   intel_dig_port->port = port;
> - dev_priv->dig_port_map[port] = intel_encoder;
>   intel_dig_port->dp.output_reg = output_reg;
>  
>   intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 4a77639a489d..23ee48dc765f 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2146,7 

[PATCH 14/42] drm/omap, omapfb: move exported dispc function declarations to omapdrm/omapfb

[Laurent Pinchart]

Hi Tomi,

On Monday 07 March 2016 10:54:05 Tomi Valkeinen wrote:
> On 07/03/16 10:42, Laurent Pinchart wrote:
> > On Monday 22 February 2016 19:10:20 Tomi Valkeinen wrote:
> >> omapdrm and omapfb still share the same include/video/omapdss.h. We need
> >> to change that so that we can proceed with omapdrm work.
> >> 
> >> However, it's not trivial to make separate omapfb and omapdrm versions
> >> of omapdss.h, as that file is also included in other places like arch
> >> code, audio code and omap_vout code. So we'll do it piece by piece.
> >> 
> >> This patch makes private versions of all the dispc function declarations
> >> that are in omapdss.h. For omapdrm we create a new file,
> >> drivers/gpu/drm/omapdrm/dss/omapdss.h, which will contain headers meant
> >> to be visible outside omapdss.
> >> 
> >> Signed-off-by: Tomi Valkeinen 
> > 
> > This looks good to me, but I would squash patches 14/42 to 16/42 together,
> > as it will make it easier to review them and make sure everything
> > relevant has been moved.
> > 
> > Could you also confirm that the idea is to move anything that is not
> > needed by arch/ code away from include/video/omapdss.h ?
> 
> My aim is to move/restructure everything shared by omapfb and omapdss so
> that they would be fully independent. But at the moment we've got
> structs used between arch/, omapfb and omapdrm, so there are some
> challenges there.
> 
> include/video/omapdss.h was needed as a public omapdss header as we had
> multiple users for omapdss. Now on the omapdrm side we no longer need a
> public header at all, so in theory all that we need in omapdss.h (from
> omapdrm's perspective) are the parts used from arch/.
> 
> But, of course, as omapfb and omap_vout still need support from
> omapdss.h, I can't remove them just like that.
> 
> Probably I should create a new header for omapfb. Or maybe a new one for
> the parts used from arch/.

Given that some of the infrastructure is shared between omapfb and omap_vout, 
I believe it would make sense to do both. 

-- 
Regards,

Laurent Pinchart

[PATCH 18/42] drm/omap: remove crtc->mgr field

[Tomi Valkeinen]

On 07/03/16 10:52, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday 22 February 2016 19:10:24 Tomi Valkeinen wrote:
>> In order to remove uses of 'struct omap_overlay_manager' from omapdrm,
>> this patch removes the crtc->mgr field.
>>
>> To accomplish that, a new static array is added along the current
>> 'omap_crtcs' static array, which is used to store the output device
>> connected to a crtc.
>>
>> Optimally we'd use the struct omap_crtc to store this information, but
>> at the time when omap_crtc_dss_connect() is called, we don't yet have
>> the omap_crtc instances. This might possibly be fixed later, but for now
>> the static array does the job.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_crtc.c | 20 +++-
>>  1 file changed, 7 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c index b1ed18bf1b1b..104e70a91fd8
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -34,14 +34,6 @@ struct omap_crtc {
>>  const char *name;
>>  enum omap_channel channel;
>>
>> -/*
>> - * Temporary: eventually this will go away, but it is needed
>> - * for now to keep the output's happy.  (They only need
>> - * mgr->id.)  Eventually this will be replaced w/ something
>> - * more common-panel-framework-y
>> - */
>> -struct omap_overlay_manager *mgr;
>> -
>>  struct omap_video_timings timings;
>>
>>  struct omap_drm_irq vblank_irq;
>> @@ -100,17 +92,20 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
>>
>>  /* ovl-mgr-id -> crtc */
>>  static struct omap_crtc *omap_crtcs[8];
>> +static struct omap_dss_device *omap_crtc_output[8];
> 
> We should really move away from global structures, not adding more of them 
> :-/ 
> Could you add this to your (or my) todo list ?

Agreed.

This restructuring series was becoming quite large and confusing
already, and I didn't see an obvious solution to this problem. So, as we
already had the omap_crtcs[], I went the easy way.

 Tomi

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

[PATCH 40/42] drm/omap: remove last uses of omap_overlay_manager

[Tomi Valkeinen]

On 07/03/16 11:01, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday 22 February 2016 19:10:46 Tomi Valkeinen wrote:
>> We have now removed all uses of 'struct omap_overlay_manager', so we can
>> now remove the last places where it is set.
> 
> Shouldn't you also move the definition of the structure to a header private 
> to 
> omapfb, as it's not used by omapdrm anymore ?

Yes if it was private to omapfb. Unfortunately omap_vout uses omapdss,
and thus omap_overlay_manager.

So more cleanup is needed...

 Tomi

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

[PATCH 17/42] drm/omap: Add dispc_mgr_get_supported_outputs()

[Tomi Valkeinen]

On 07/03/16 10:47, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday 22 February 2016 19:10:23 Tomi Valkeinen wrote:
>> We are removing the use of the 'struct omap_overlay_manager' from
>> omapdrm, and one part of that is removing the use of
>> mgr->supported_outputs field.
>>
>> This patch adds dispc_mgr_get_supported_outputs() function which can be
>> used instead of mgr->supported_outputs. omap_crtc.c is changed to use
>> the new function.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 6 ++
>>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 ++
>>  drivers/gpu/drm/omapdrm/omap_crtc.c   | 2 +-
>>  3 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> b/drivers/gpu/drm/omapdrm/dss/dispc.c index a4274dca384a..a5940892a788
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
>> @@ -2910,6 +2910,12 @@ bool dispc_ovl_enabled(enum omap_plane plane)
>>  }
>>  EXPORT_SYMBOL(dispc_ovl_enabled);
>>
>> +enum omap_dss_output_id dispc_mgr_get_supported_outputs(enum omap_channel
>> channel)
>> +{
>> +return dss_feat_get_supported_outputs(channel);
>> +}
> 
> Wouldn't it make sense to turn this into a static inline function, as it's a 
> one-liner ?

I plan to get rid of the dss_features.c and move the code into
respective driver files. So this function will probably get a bit larger
with that.

And hmm... Would it even work, as dss_feat_get_supported_outputs() is
not visible to the callers?

 Tomi

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

[PATCH 40/42] drm/omap: remove last uses of omap_overlay_manager

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:46 Tomi Valkeinen wrote:
> We have now removed all uses of 'struct omap_overlay_manager', so we can
> now remove the last places where it is set.

Shouldn't you also move the definition of the structure to a header private to 
omapfb, as it's not used by omapdrm anymore ?

> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c index f195641b510c..932196e30024
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -98,8 +98,6 @@ static struct omap_dss_device *omap_crtc_output[8];
>  static int omap_crtc_dss_connect(enum omap_channel channel,
>   struct omap_dss_device *dst)
>  {
> - struct omap_overlay_manager *mgr = 
> omap_dss_get_overlay_manager(channel);
> -
>   if (omap_crtc_output[channel])
>   return -EINVAL;
> 
> @@ -109,22 +107,14 @@ static int omap_crtc_dss_connect(enum omap_channel
> channel, omap_crtc_output[channel] = dst;
>   dst->dispc_channel_connected = true;
> 
> - dst->manager = mgr;
> - mgr->output = dst;
> -
>   return 0;
>  }
> 
>  static void omap_crtc_dss_disconnect(enum omap_channel channel,
>   struct omap_dss_device *dst)
>  {
> - struct omap_overlay_manager *mgr = 
> omap_dss_get_overlay_manager(channel);
> -
>   omap_crtc_output[channel] = NULL;
>   dst->dispc_channel_connected = false;
> -
> - mgr->output->manager = NULL;
> - mgr->output = NULL;
>  }
> 
>  static void omap_crtc_dss_start_update(enum omap_channel channel)

-- 
Regards,

Laurent Pinchart

[PATCH 14/42] drm/omap, omapfb: move exported dispc function declarations to omapdrm/omapfb

[Tomi Valkeinen]

On 07/03/16 10:42, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday 22 February 2016 19:10:20 Tomi Valkeinen wrote:
>> omapdrm and omapfb still share the same include/video/omapdss.h. We need
>> to change that so that we can proceed with omapdrm work.
>>
>> However, it's not trivial to make separate omapfb and omapdrm versions
>> of omapdss.h, as that file is also included in other places like arch
>> code, audio code and omap_vout code. So we'll do it piece by piece.
>>
>> This patch makes private versions of all the dispc function declarations
>> that are in omapdss.h. For omapdrm we create a new file,
>> drivers/gpu/drm/omapdrm/dss/omapdss.h, which will contain headers meant
>> to be visible outside omapdss.
>>
>> Signed-off-by: Tomi Valkeinen 
> 
> This looks good to me, but I would squash patches 14/42 to 16/42 together, as 
> it will make it easier to review them and make sure everything relevant has 
> been moved.
> 
> Could you also confirm that the idea is to move anything that is not needed 
> by 
> arch/ code away from include/video/omapdss.h ?

My aim is to move/restructure everything shared by omapfb and omapdss so
that they would be fully independent. But at the moment we've got
structs used between arch/, omapfb and omapdrm, so there are some
challenges there.

include/video/omapdss.h was needed as a public omapdss header as we had
multiple users for omapdss. Now on the omapdrm side we no longer need a
public header at all, so in theory all that we need in omapdss.h (from
omapdrm's perspective) are the parts used from arch/.

But, of course, as omapfb and omap_vout still need support from
omapdss.h, I can't remove them just like that.

Probably I should create a new header for omapfb. Or maybe a new one for
the parts used from arch/.

 Tomi

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

[PATCH 18/42] drm/omap: remove crtc->mgr field

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:24 Tomi Valkeinen wrote:
> In order to remove uses of 'struct omap_overlay_manager' from omapdrm,
> this patch removes the crtc->mgr field.
> 
> To accomplish that, a new static array is added along the current
> 'omap_crtcs' static array, which is used to store the output device
> connected to a crtc.
> 
> Optimally we'd use the struct omap_crtc to store this information, but
> at the time when omap_crtc_dss_connect() is called, we don't yet have
> the omap_crtc instances. This might possibly be fixed later, but for now
> the static array does the job.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 20 +++-
>  1 file changed, 7 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c index b1ed18bf1b1b..104e70a91fd8
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -34,14 +34,6 @@ struct omap_crtc {
>   const char *name;
>   enum omap_channel channel;
> 
> - /*
> -  * Temporary: eventually this will go away, but it is needed
> -  * for now to keep the output's happy.  (They only need
> -  * mgr->id.)  Eventually this will be replaced w/ something
> -  * more common-panel-framework-y
> -  */
> - struct omap_overlay_manager *mgr;
> -
>   struct omap_video_timings timings;
> 
>   struct omap_drm_irq vblank_irq;
> @@ -100,17 +92,20 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
> 
>  /* ovl-mgr-id -> crtc */
>  static struct omap_crtc *omap_crtcs[8];
> +static struct omap_dss_device *omap_crtc_output[8];

We should really move away from global structures, not adding more of them :-/ 
Could you add this to your (or my) todo list ?

>  /* we can probably ignore these until we support command-mode panels: */
>  static int omap_crtc_dss_connect(struct omap_overlay_manager *mgr,
>   struct omap_dss_device *dst)
>  {
> - if (mgr->output)
> + if (omap_crtc_output[mgr->id])
>   return -EINVAL;
> 
>   if ((dispc_mgr_get_supported_outputs(mgr->id) & dst->id) == 0)
>   return -EINVAL;
> 
> + omap_crtc_output[mgr->id] = dst;
> +
>   dst->manager = mgr;
>   mgr->output = dst;
> 
> @@ -120,6 +115,8 @@ static int omap_crtc_dss_connect(struct
> omap_overlay_manager *mgr, static void omap_crtc_dss_disconnect(struct
> omap_overlay_manager *mgr, struct omap_dss_device *dst)
>  {
> + omap_crtc_output[mgr->id] = NULL;
> +
>   mgr->output->manager = NULL;
>   mgr->output = NULL;
>  }
> @@ -138,7 +135,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc,
> bool enable) u32 framedone_irq, vsync_irq;
>   int ret;
> 
> - if (omap_crtc->mgr->output->output_type == OMAP_DISPLAY_TYPE_HDMI) {
> + if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
>   dispc_mgr_enable(channel, enable);
>   return;
>   }
> @@ -547,9 +544,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>   omap_crtc->error_irq.irq = omap_crtc_error_irq;
>   omap_irq_register(dev, _crtc->error_irq);
> 
> - /* temporary: */
> - omap_crtc->mgr = omap_dss_get_overlay_manager(channel);
> -
>   ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
>   _crtc_funcs, NULL);
>   if (ret < 0) {

-- 
Regards,

Laurent Pinchart

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

[Doug Anderson]

Hi,

On Mon, Mar 7, 2016 at 9:57 AM, Heiko Stübner  wrote:
> Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
>> Hi,
>>
>> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao  wrote:
>> > On 2016年03月05日 20:39, Russell King - ARM Linux wrote:
>> >> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
>> >>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
>>  The drm_encoder_cleanup() was missing both from the error path of
>>  dw_hdmi_rockchip_bind().  This caused a crash when slub_debug was
>>  enabled and we ended up deferring probe of HDMI at boot.
>> 
>>  This call isn't needed from unbind() because if dw_hdmi_bind() returns
>>  no error then it takes over the job of freeing the encoder (in
>>  dw_hdmi_unbind).
>> 
>>  Signed-off-by: Douglas Anderson 
>>  ---
>> >>>
>> >>> Does dw_hdmi-imx need a similar change?  I wonder if it would be cleaner
>> >>> to push this into dw_hdmi_bind() if it affects all of the platforms..
>> >>
>> >> I don't think moving it there would make sense - keep the initialisation
>> >> and cleanup together in the same file so that it's contained together.
>> >
>> > I don't like this patch too, initialisation and cleanup not in the same
>> > file looks bad,
>> >
>> > How about:
>> >
>> > drivers/gpu/drm/bridge/dw-hdmi.c
>> > void dw_hdmi_unbind(struct device *dev, struct device *master, void *data)
>> >
>> > hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
>> >
>> > hdmi->connector.funcs->destroy(>connector);
>> > -   hdmi->encoder->funcs->destroy(hdmi->encoder);
>> >
>> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> > static int dw_hdmi_rockchip_bind(struct device *dev, struct device
>> > *master,
>> >
>> > -   return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
>> > plat_data);
>> > +   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq,
>> > plat_data);
>> > +   if (ret)
>> > +   drm_encoder_cleanup(encoder);
>> > +
>> > +   return ret;
>> >
>> >  }
>> >
>> >  static void dw_hdmi_rockchip_unbind(struct device *dev, struct device
>> >
>> > *master,
>> >
>> > void *data)
>> >
>> >  {
>> >
>> > +   drm_encoder_cleanup(...);
>> >
>> > return dw_hdmi_unbind(dev, master, data);
>> >
>> >  }
>>
>> That'a a reasonable suggestion in theory.  ...but we run into the same
>> problem I've run into before with the strange relationship between
>> dw_hdmi and its descendants.
>
> I don't think handing off the cleanup responsibility is really in question
> here. I.e. I do believe it should also be fine to expect (as definition) the
> core driver to cleanup the encoder _after_ it sucessfully claimed it in
> dw_hdmi_bind().
>
> We do the same in the rockchip power-domains, handing off the struct clk-
> pointer to the pm_clk stuff (due to the clk-pointer being unique per-device
> nowadays).
>
> So just making sure it is sucessfully handed off should also be ok.

If I understand correctly, that means you'd be OK with the original
patch I posted?  In that case cleanup continues to happen in the main
dw-hdmi.c if dw_hdmi_bind() succeeds and my patch fixes the cleanup
when dw_hdmi_bind() fails (and thus cleanup responsibility was not
handed off).

Also: I noticed that Russell also didn't seem to say that my original
patch was bad.  I think he just said that he didn't like John
Keeping's suggestion.

Please correct any misunderstandings.  Thanks!

-Doug

[PATCH 17/42] drm/omap: Add dispc_mgr_get_supported_outputs()

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:23 Tomi Valkeinen wrote:
> We are removing the use of the 'struct omap_overlay_manager' from
> omapdrm, and one part of that is removing the use of
> mgr->supported_outputs field.
> 
> This patch adds dispc_mgr_get_supported_outputs() function which can be
> used instead of mgr->supported_outputs. omap_crtc.c is changed to use
> the new function.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 6 ++
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 ++
>  drivers/gpu/drm/omapdrm/omap_crtc.c   | 2 +-
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index a4274dca384a..a5940892a788
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2910,6 +2910,12 @@ bool dispc_ovl_enabled(enum omap_plane plane)
>  }
>  EXPORT_SYMBOL(dispc_ovl_enabled);
> 
> +enum omap_dss_output_id dispc_mgr_get_supported_outputs(enum omap_channel
> channel)
> +{
> + return dss_feat_get_supported_outputs(channel);
> +}

Wouldn't it make sense to turn this into a static inline function, as it's a 
one-liner ?

> +EXPORT_SYMBOL(dispc_mgr_get_supported_outputs);
> +
>  void dispc_mgr_enable(enum omap_channel channel, bool enable)
>  {
>   mgr_fld_write(channel, DISPC_MGR_FLD_ENABLE, enable);
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h index 7712ffef2836..0a213489f133
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -58,6 +58,8 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
> omap_overlay_info *oi, bool replication, const struct omap_video_timings
> *mgr_timings, bool mem_to_mem);
> 
> +enum omap_dss_output_id dispc_mgr_get_supported_outputs(enum omap_channel
> channel); +
>  struct dss_mgr_ops {
>   int (*connect)(struct omap_overlay_manager *mgr,
>   struct omap_dss_device *dst);
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c index 280d80781635..b1ed18bf1b1b
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -108,7 +108,7 @@ static int omap_crtc_dss_connect(struct
> omap_overlay_manager *mgr, if (mgr->output)
>   return -EINVAL;
> 
> - if ((mgr->supported_outputs & dst->id) == 0)
> + if ((dispc_mgr_get_supported_outputs(mgr->id) & dst->id) == 0)
>   return -EINVAL;
> 
>   dst->manager = mgr;

-- 
Regards,

Laurent Pinchart

enable display using drm

[Pekka Paalanen]

On Tue, 1 Mar 2016 12:47:57 +0100
Alex Vazquez  wrote:

> Hi. I want to know if it's possible (enable/disable) the display using some
> function of drm. I have looking for but I don't find nothing about this.

Hi,

it's possible only if the code doing that is the display server or equivalent.


Thanks,
pq
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/092dc2bc/attachment.sig>

[PATCH 14/42] drm/omap, omapfb: move exported dispc function declarations to omapdrm/omapfb

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:20 Tomi Valkeinen wrote:
> omapdrm and omapfb still share the same include/video/omapdss.h. We need
> to change that so that we can proceed with omapdrm work.
> 
> However, it's not trivial to make separate omapfb and omapdrm versions
> of omapdss.h, as that file is also included in other places like arch
> code, audio code and omap_vout code. So we'll do it piece by piece.
> 
> This patch makes private versions of all the dispc function declarations
> that are in omapdss.h. For omapdrm we create a new file,
> drivers/gpu/drm/omapdrm/dss/omapdss.h, which will contain headers meant
> to be visible outside omapdss.
> 
> Signed-off-by: Tomi Valkeinen 

This looks good to me, but I would squash patches 14/42 to 16/42 together, as 
it will make it easier to review them and make sure everything relevant has 
been moved.

Could you also confirm that the idea is to move anything that is not needed by 
arch/ code away from include/video/omapdss.h ?

> ---
>  drivers/gpu/drm/omapdrm/dss/dss.h|  2 +
>  drivers/gpu/drm/omapdrm/dss/omapdss.h| 61 +
>  drivers/gpu/drm/omapdrm/omap_drv.h   |  2 +
>  drivers/video/fbdev/omap2/omapfb/dss/dispc.h |  1 +
>  drivers/video/fbdev/omap2/omapfb/dss/dss.h   | 38 +
>  include/video/omapdss.h  | 38 -
>  6 files changed, 104 insertions(+), 38 deletions(-)
>  create mode 100644 drivers/gpu/drm/omapdrm/dss/omapdss.h

[snip]

> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.h
> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.h index
> 483744223dd1..e014d0419c58 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.h
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.h
> @@ -915,4 +915,5 @@ static inline u16 DISPC_MFLAG_THRESHOLD_OFFSET(enum
> omap_plane plane) return 0;
>   }
>  }
> +
>  #endif

Unrelated change ?

-- 
Regards,

Laurent Pinchart

[PATCH 0/8] drm/bochs: convert bochs to atomic mode-setting

[Gerd Hoffmann]

  Hi,

> > Digged the mails up in the archive.
> >
> Silly me assumed that the MUA will bring up the the whole thread.

If your mbox goes back that far ...

I usually have a few months history in my mailbox folders which is
enough in the vast majority of the cases where I have to check some past
mail, but wasn't in this case.

> Pretty sure that's intentional since only the first patch has changed.
> Up-to recently that was the more commonly used approach on dri-devel.

Ah, ok.  That explains it.

> > John pointed me to
> > https://github.com/zhjwpku/gsoc/commits/20150720_no_gpu_addr which I've
> > used to test things.
> >
> > Second, page flipping failed in testing.

> If you can share some tips about the testing procedure and/or actual
> issue that would be beneficial.

Simple: wayland breaks.  kmscon uses pageflips too and can also be used
for testing (and this is alot easier in case your distro hasn't packaged
up wayland).

cheers,
  Gerd

[PATCH 07/42] drm/omap: connector-dvi: remove pdata support

[Tomi Valkeinen]

On 07/03/16 10:16, Laurent Pinchart wrote:

>> @@ -319,17 +279,12 @@ static int dvic_probe(struct platform_device *pdev)
>>
>>  platform_set_drvdata(pdev, ddata);
>>
>> -if (dev_get_platdata(>dev)) {
>> -r = dvic_probe_pdata(pdev);
>> -if (r)
>> -return r;
>> -} else if (pdev->dev.of_node) {
>> -r = dvic_probe_of(pdev);
>> -if (r)
>> -return r;
>> -} else {
>> +if (pdev->dev.of_node)
> 
> I think you need to invert the condition.

Thanks! Well, I obviously wasn't too careful here... I'll go through all
of them.

 Tomi

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

[PATCH 07/42] drm/omap: connector-dvi: remove pdata support

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:13 Tomi Valkeinen wrote:
> We no longer have any boards that require the platform data support from
> the connector, so we can remove the related code.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 55  +++-
>  1 file changed, 5 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c index
> d811e6dcaef7..3fd5a0b4d4cf 100644
> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> @@ -236,46 +236,6 @@ static struct omap_dss_driver dvic_driver = {
>   .detect = dvic_detect,
>  };
> 
> -static int dvic_probe_pdata(struct platform_device *pdev)
> -{
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> - struct connector_dvi_platform_data *pdata;
> - struct omap_dss_device *in, *dssdev;
> - int i2c_bus_num;
> -
> - pdata = dev_get_platdata(>dev);
> - i2c_bus_num = pdata->i2c_bus_num;
> -
> - if (i2c_bus_num != -1) {
> - struct i2c_adapter *adapter;
> -
> - adapter = i2c_get_adapter(i2c_bus_num);
> - if (!adapter) {
> - dev_err(>dev,
> - "Failed to get I2C adapter, bus %d\n",
> - i2c_bus_num);
> - return -EPROBE_DEFER;
> - }
> -
> - ddata->i2c_adapter = adapter;
> - }
> -
> - in = omap_dss_find_output(pdata->source);
> - if (in == NULL) {
> - i2c_put_adapter(ddata->i2c_adapter);
> -
> - dev_err(>dev, "Failed to find video source\n");
> - return -EPROBE_DEFER;
> - }
> -
> - ddata->in = in;
> -
> - dssdev = >dssdev;
> - dssdev->name = pdata->name;
> -
> - return 0;
> -}
> -
>  static int dvic_probe_of(struct platform_device *pdev)
>  {
>   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> @@ -319,17 +279,12 @@ static int dvic_probe(struct platform_device *pdev)
> 
>   platform_set_drvdata(pdev, ddata);
> 
> - if (dev_get_platdata(>dev)) {
> - r = dvic_probe_pdata(pdev);
> - if (r)
> - return r;
> - } else if (pdev->dev.of_node) {
> - r = dvic_probe_of(pdev);
> - if (r)
> - return r;
> - } else {
> + if (pdev->dev.of_node)

I think you need to invert the condition.

>   return -ENODEV;
> - }
> +
> + r = dvic_probe_of(pdev);
> + if (r)
> + return r;
> 
>   ddata->timings = dvic_default_timings;

-- 
Regards,

Laurent Pinchart

[PATCH 05/42] drm/omap: panel-dsi-cm: remove pdata support

[Tomi Valkeinen]

On 07/03/16 10:04, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> On Monday 22 February 2016 19:10:11 Tomi Valkeinen wrote:
>> We no longer have any boards that require the platform data support from
>> the panel, so we can remove the related code.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 49  +++--
> 
> I was about to say that you can also remove the definition of the 
> panel_dsicm_platform_data structure in include/video/omap-panel-data.h, but 
> you have to keep it for the display drivers in the omapfb driver. I wonder 
> whether you shouldn't also remove pdata support there as well to be able to 
> clean the shared headers. This also applies to patches 06/42 to 13/42.

Yes, I'm planning to do some cleaning on that side too. But I only have
so much time... =). I didn't want to mix up omapfb and omapdrm changes
in this same series.

>>  1 file changed, 5 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c index
>> 3414c2609320..ae7dd625e19f 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>> @@ -1127,40 +1127,6 @@ static struct omap_dss_driver dsicm_ops = {
>>  .memory_read= dsicm_memory_read,
>>  };
>>
>> -static int dsicm_probe_pdata(struct platform_device *pdev)
>> -{
>> -const struct panel_dsicm_platform_data *pdata;
>> -struct panel_drv_data *ddata = platform_get_drvdata(pdev);
>> -struct omap_dss_device *dssdev, *in;
>> -
>> -pdata = dev_get_platdata(>dev);
>> -
>> -in = omap_dss_find_output(pdata->source);
>> -if (in == NULL) {
>> -dev_err(>dev, "failed to find video source\n");
>> -return -EPROBE_DEFER;
>> -}
>> -ddata->in = in;
>> -
>> -ddata->reset_gpio = pdata->reset_gpio;
>> -
>> -if (pdata->use_ext_te)
>> -ddata->ext_te_gpio = pdata->ext_te_gpio;
>> -else
>> -ddata->ext_te_gpio = -1;
>> -
>> -ddata->ulps_timeout = pdata->ulps_timeout;
>> -
>> -ddata->use_dsi_backlight = pdata->use_dsi_backlight;
>> -
>> -ddata->pin_config = pdata->pin_config;
>> -
>> -dssdev = >dssdev;
>> -dssdev->name = pdata->name;
>> -
>> -return 0;
>> -}
>> -
>>  static int dsicm_probe_of(struct platform_device *pdev)
>>  {
>>  struct device_node *node = pdev->dev.of_node;
>> @@ -1214,17 +1180,12 @@ static int dsicm_probe(struct platform_device *pdev)
>> platform_set_drvdata(pdev, ddata);
>>  ddata->pdev = pdev;
>>
>> -if (dev_get_platdata(dev)) {
>> -r = dsicm_probe_pdata(pdev);
>> -if (r)
>> -return r;
>> -} else if (pdev->dev.of_node) {
>> -r = dsicm_probe_of(pdev);
>> -if (r)
>> -return r;
>> -} else {
>> +if (pdev->dev.of_node)
> 
> Shouldn't you invert the condition ?

Oops... Thanks for catching this.

 Tomi

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

[PATCH 05/42] drm/omap: panel-dsi-cm: remove pdata support

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.
On Monday 22 February 2016 19:10:11 Tomi Valkeinen wrote:
> We no longer have any boards that require the platform data support from
> the panel, so we can remove the related code.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 49  +++--

I was about to say that you can also remove the definition of the 
panel_dsicm_platform_data structure in include/video/omap-panel-data.h, but 
you have to keep it for the display drivers in the omapfb driver. I wonder 
whether you shouldn't also remove pdata support there as well to be able to 
clean the shared headers. This also applies to patches 06/42 to 13/42.

>  1 file changed, 5 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c index
> 3414c2609320..ae7dd625e19f 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> @@ -1127,40 +1127,6 @@ static struct omap_dss_driver dsicm_ops = {
>   .memory_read= dsicm_memory_read,
>  };
> 
> -static int dsicm_probe_pdata(struct platform_device *pdev)
> -{
> - const struct panel_dsicm_platform_data *pdata;
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> - struct omap_dss_device *dssdev, *in;
> -
> - pdata = dev_get_platdata(>dev);
> -
> - in = omap_dss_find_output(pdata->source);
> - if (in == NULL) {
> - dev_err(>dev, "failed to find video source\n");
> - return -EPROBE_DEFER;
> - }
> - ddata->in = in;
> -
> - ddata->reset_gpio = pdata->reset_gpio;
> -
> - if (pdata->use_ext_te)
> - ddata->ext_te_gpio = pdata->ext_te_gpio;
> - else
> - ddata->ext_te_gpio = -1;
> -
> - ddata->ulps_timeout = pdata->ulps_timeout;
> -
> - ddata->use_dsi_backlight = pdata->use_dsi_backlight;
> -
> - ddata->pin_config = pdata->pin_config;
> -
> - dssdev = >dssdev;
> - dssdev->name = pdata->name;
> -
> - return 0;
> -}
> -
>  static int dsicm_probe_of(struct platform_device *pdev)
>  {
>   struct device_node *node = pdev->dev.of_node;
> @@ -1214,17 +1180,12 @@ static int dsicm_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, ddata);
>   ddata->pdev = pdev;
> 
> - if (dev_get_platdata(dev)) {
> - r = dsicm_probe_pdata(pdev);
> - if (r)
> - return r;
> - } else if (pdev->dev.of_node) {
> - r = dsicm_probe_of(pdev);
> - if (r)
> - return r;
> - } else {
> + if (pdev->dev.of_node)

Shouldn't you invert the condition ?

>   return -ENODEV;
> - }
> +
> + r = dsicm_probe_of(pdev);
> + if (r)
> + return r;
> 
>   ddata->timings.x_res = 864;
>   ddata->timings.y_res = 480;

-- 
Regards,

Laurent Pinchart

[PATCH 01/42] drm/omap: fix suspend/resume handling

[Tomi Valkeinen]

-
>>  void dss_disable_all_devices(void)
>>  {
>>  struct omap_dss_device *dssdev = NULL;
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
>> b/drivers/gpu/drm/omapdrm/dss/dss.h index 9a6453235585..a974d46672db 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
>> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
>> @@ -206,8 +206,6 @@ int dss_set_min_bus_tput(struct device *dev, unsigned
>> long tput); int dss_debugfs_create_file(const char *name, void
>> (*write)(struct seq_file *));
>>
>>  /* display */
>> -int dss_suspend_all_devices(void);
>> -int dss_resume_all_devices(void);
>>  void dss_disable_all_devices(void);
>>
>>  int display_init_sysfs(struct platform_device *pdev);
>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>> b/drivers/gpu/drm/omapdrm/omap_drv.c index dfafdb602ad2..e21433c3fda4
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> @@ -900,12 +900,52 @@ static int pdev_remove(struct platform_device *device)
>> }
>>
>>  #ifdef CONFIG_PM_SLEEP
>> +static int omap_drm_suspend_all_displays(void)
>> +{
>> +struct omap_dss_device *dssdev = NULL;
>> +
>> +for_each_dss_dev(dssdev) {
>> +if (!dssdev->driver)
>> +continue;
>> +
>> +if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE) {
>> +dssdev->driver->disable(dssdev);
>> +dssdev->activate_after_resume = true;
>> +} else {
>> +dssdev->activate_after_resume = false;
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int omap_drm_resume_all_displays(void)
>> +{
>> +struct omap_dss_device *dssdev = NULL;
>> +
>> +for_each_dss_dev(dssdev) {
>> +if (!dssdev->driver)
>> +continue;
>> +
>> +if (dssdev->activate_after_resume) {
>> +dssdev->driver->enable(dssdev);
>> +dssdev->activate_after_resume = false;
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  static int omap_drm_suspend(struct device *dev)
>>  {
>>  struct drm_device *drm_dev = dev_get_drvdata(dev);
>>
>>  drm_kms_helper_poll_disable(drm_dev);
>>
>> +drm_modeset_lock_all(drm_dev);
> 
> The omapdss implementation of the suspend and resume handlers didn't take the 
> modeset locks. I wonder what we're trying to protect against here, what other 
> concurrent task(s) could race us ?

The description explains at least one case I was encountering. To be
honest, the new code doesn't feel very good either, but at least the
entry point is now in omapdrm, and protected with a lock, so it should
be much safer.

As for what else is there... I hope not much. The panel/encoder drivers
can execute code in an interrupt or possibly even via a sysfs file if
someone would add things like that, and at the moment we don't have
means to properly deal with it. But afaik the current drivers don't do
any of those.

 Tomi

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

[PATCH 04/42] drm/omap: omapdss.h: remove omap_hdmi_init

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:10 Tomi Valkeinen wrote:
> omap_hdmi_init() function does not exist anymore, so we can remove the
> declaration.
> 
> Signed-off-by: Tomi Valkeinen 

Acked-by: Laurent Pinchart 

> ---
>  include/video/omapdss.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 07c7d993c021..7a2724e1622f 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -332,8 +332,6 @@ struct omap_dss_board_info {
> 
>  /* Init with the board info */
>  extern int omap_display_init(struct omap_dss_board_info *board_data);
> -/* HDMI mux init*/
> -extern int omap_hdmi_init(enum omap_hdmi_flags flags);
> 
>  struct omap_video_timings {
>   /* Unit: pixels */

-- 
Regards,

Laurent Pinchart

[PATCH 03/42] drm/omap: omapdss.h: remove unused struct omap_dss_hdmi_data

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:09 Tomi Valkeinen wrote:
> 'struct omap_dss_hdmi_data' is not used anywhere, so we can remove it.
> 
> Signed-off-by: Tomi Valkeinen 

Acked-by: Laurent Pinchart 

> ---
>  include/video/omapdss.h | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 6c1a3e1b4d55..07c7d993c021 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -785,13 +785,6 @@ struct omap_dss_device {
>   struct omap_dss_device *dst;
>  };
> 
> -struct omap_dss_hdmi_data
> -{
> - int ct_cp_hpd_gpio;
> - int ls_oe_gpio;
> - int hpd_gpio;
> -};
> -
>  struct omap_dss_driver {
>   int (*probe)(struct omap_dss_device *);
>   void (*remove)(struct omap_dss_device *);

-- 
Regards,

Laurent Pinchart

[PATCH 02/42] drm/omap: move dss_suspend/resume_all to core.c

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:08 Tomi Valkeinen wrote:
> core.c is the only caller of dss_disable_all_devices(). We can thus move
> the function from display.c to core.c and make it static.
> 
> Signed-off-by: Tomi Valkeinen 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/core.c| 13 +
>  drivers/gpu/drm/omapdrm/dss/display.c | 13 -
>  drivers/gpu/drm/omapdrm/dss/dss.h |  2 --
>  3 files changed, 13 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
> b/drivers/gpu/drm/omapdrm/dss/core.c index 1f55d0aae03d..7e4e5bebabbe
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/core.c
> +++ b/drivers/gpu/drm/omapdrm/dss/core.c
> @@ -166,6 +166,19 @@ int dss_debugfs_create_file(const char *name, void
> (*write)(struct seq_file *))
> 
>  /* PLATFORM DEVICE */
> 
> +static void dss_disable_all_devices(void)
> +{
> + struct omap_dss_device *dssdev = NULL;
> +
> + for_each_dss_dev(dssdev) {
> + if (!dssdev->driver)
> + continue;
> +
> + if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
> + dssdev->driver->disable(dssdev);
> + }
> +}
> +
>  static int __init omap_dss_probe(struct platform_device *pdev)
>  {
>   struct omap_dss_board_info *pdata = pdev->dev.platform_data;
> diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
> b/drivers/gpu/drm/omapdrm/dss/display.c index 24c2bffa0036..9f3dd09b0a6c
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/display.c
> +++ b/drivers/gpu/drm/omapdrm/dss/display.c
> @@ -78,19 +78,6 @@ void omapdss_default_get_timings(struct omap_dss_device
> *dssdev, }
>  EXPORT_SYMBOL(omapdss_default_get_timings);
> 
> -void dss_disable_all_devices(void)
> -{
> - struct omap_dss_device *dssdev = NULL;
> -
> - for_each_dss_dev(dssdev) {
> - if (!dssdev->driver)
> - continue;
> -
> - if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
> - dssdev->driver->disable(dssdev);
> - }
> -}
> -
>  static LIST_HEAD(panel_list);
>  static DEFINE_MUTEX(panel_list_mutex);
>  static int disp_num_counter;
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
> b/drivers/gpu/drm/omapdrm/dss/dss.h index a974d46672db..56ce89d4be27 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
> @@ -206,8 +206,6 @@ int dss_set_min_bus_tput(struct device *dev, unsigned
> long tput); int dss_debugfs_create_file(const char *name, void
> (*write)(struct seq_file *));
> 
>  /* display */
> -void dss_disable_all_devices(void);
> -
>  int display_init_sysfs(struct platform_device *pdev);
>  void display_uninit_sysfs(struct platform_device *pdev);

-- 
Regards,

Laurent Pinchart

[PATCH 01/42] drm/omap: fix suspend/resume handling

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Monday 22 February 2016 19:10:07 Tomi Valkeinen wrote:
> For legacy reasons omapdss handles system suspend/resume via PM notifier
> callback, where the driver disables/resumes all the outputs.
> 
> This doesn't work well with omapdrm. What happens on suspend is that the
> omapdss disables the displays while omapdrm is still happily continuing
> its work, possibly waiting for an vsync irq, which will never come if
> the display output is disabled, leading to timeouts and errors sent to
> userspace.
> 
> This patch moves the suspend/resume handling to omapdrm, and the
> suspend/resume is now done safely inside modeset lock.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/dss/core.c| 29 ---
>  drivers/gpu/drm/omapdrm/dss/display.c | 36 
>  drivers/gpu/drm/omapdrm/dss/dss.h |  2 --
>  drivers/gpu/drm/omapdrm/omap_drv.c| 44 
>  4 files changed, 44 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
> b/drivers/gpu/drm/omapdrm/dss/core.c index 54eeb507f9b3..1f55d0aae03d
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/core.c
> +++ b/drivers/gpu/drm/omapdrm/dss/core.c
> @@ -165,31 +165,6 @@ int dss_debugfs_create_file(const char *name, void
> (*write)(struct seq_file *)) #endif /* CONFIG_OMAP2_DSS_DEBUGFS */
> 
>  /* PLATFORM DEVICE */
> -static int omap_dss_pm_notif(struct notifier_block *b, unsigned long v,
> void *d) -{
> - DSSDBG("pm notif %lu\n", v);
> -
> - switch (v) {
> - case PM_SUSPEND_PREPARE:
> - case PM_HIBERNATION_PREPARE:
> - case PM_RESTORE_PREPARE:
> - DSSDBG("suspending displays\n");
> - return dss_suspend_all_devices();
> -
> - case PM_POST_SUSPEND:
> - case PM_POST_HIBERNATION:
> - case PM_POST_RESTORE:
> - DSSDBG("resuming displays\n");
> - return dss_resume_all_devices();
> -
> - default:
> - return 0;
> - }
> -}
> -
> -static struct notifier_block omap_dss_pm_notif_block = {
> - .notifier_call = omap_dss_pm_notif,
> -};
> 
>  static int __init omap_dss_probe(struct platform_device *pdev)
>  {
> @@ -211,8 +186,6 @@ static int __init omap_dss_probe(struct platform_device
> *pdev) else if (pdata->default_device)
>   core.default_display_name = pdata->default_device->name;
> 
> - register_pm_notifier(_dss_pm_notif_block);
> -
>   return 0;
> 
>  err_debugfs:
> @@ -222,8 +195,6 @@ err_debugfs:
> 
>  static int omap_dss_remove(struct platform_device *pdev)
>  {
> - unregister_pm_notifier(_dss_pm_notif_block);
> -
>   dss_uninitialize_debugfs();
> 
>   return 0;
> diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
> b/drivers/gpu/drm/omapdrm/dss/display.c index ef5b9027985d..24c2bffa0036
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/display.c
> +++ b/drivers/gpu/drm/omapdrm/dss/display.c
> @@ -78,42 +78,6 @@ void omapdss_default_get_timings(struct omap_dss_device
> *dssdev, }
>  EXPORT_SYMBOL(omapdss_default_get_timings);
> 
> -int dss_suspend_all_devices(void)
> -{
> - struct omap_dss_device *dssdev = NULL;
> -
> - for_each_dss_dev(dssdev) {
> - if (!dssdev->driver)
> - continue;
> -
> - if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE) {
> - dssdev->driver->disable(dssdev);
> - dssdev->activate_after_resume = true;
> - } else {
> - dssdev->activate_after_resume = false;
> - }
> - }
> -
> - return 0;
> -}
> -
> -int dss_resume_all_devices(void)
> -{
> - struct omap_dss_device *dssdev = NULL;
> -
> - for_each_dss_dev(dssdev) {
> - if (!dssdev->driver)
> - continue;
> -
> - if (dssdev->activate_after_resume) {
> - dssdev->driver->enable(dssdev);
> - dssdev->activate_after_resume = false;
> - }
> - }
> -
> - return 0;
> -}
> -
>  void dss_disable_all_devices(void)
>  {
>   struct omap_dss_device *dssdev = NULL;
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
> b/drivers/gpu/drm/omapdrm/dss/dss.h index 9a6453235585..a974d46672db 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
> @@ -206,8 +206,6 @@ int dss_set_min_bus_tput(struct device *dev, unsigned
> long tput); int dss_debugfs_create_file(const char *name, void
> (*write)(struct seq_file *));
> 
>  /* display */
> -int dss_suspend_all_devices(void);
> -int dss_resume_all_devices(void);
>  void dss_disable_all_devices(void);
> 
>  int display_init_sysfs(struct platform_device *pdev);
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index dfafdb602ad2..e21433c3fda4
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -900,12 +900,52 @@ static int 

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

[Doug Anderson]

Hi,

On Mon, Mar 7, 2016 at 12:37 AM, Mark yao  wrote:
> On 2016年03月05日 20:39, Russell King - ARM Linux wrote:
>>
>> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
>>>
>>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:

 The drm_encoder_cleanup() was missing both from the error path of
 dw_hdmi_rockchip_bind().  This caused a crash when slub_debug was
 enabled and we ended up deferring probe of HDMI at boot.

 This call isn't needed from unbind() because if dw_hdmi_bind() returns
 no error then it takes over the job of freeing the encoder (in
 dw_hdmi_unbind).

 Signed-off-by: Douglas Anderson 
 ---
>>>
>>> Does dw_hdmi-imx need a similar change?  I wonder if it would be cleaner
>>> to push this into dw_hdmi_bind() if it affects all of the platforms..
>>
>> I don't think moving it there would make sense - keep the initialisation
>> and cleanup together in the same file so that it's contained together.
>>
>
> I don't like this patch too, initialisation and cleanup not in the same file
> looks bad,
>
> How about:
>
> drivers/gpu/drm/bridge/dw-hdmi.c
> void dw_hdmi_unbind(struct device *dev, struct device *master, void *data)
> hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
>
> hdmi->connector.funcs->destroy(>connector);
> -   hdmi->encoder->funcs->destroy(hdmi->encoder);
>
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
>
> -   return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> plat_data);
> +   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq,
> plat_data);
> +   if (ret)
> +   drm_encoder_cleanup(encoder);
> +
> +   return ret;
>  }
>
>  static void dw_hdmi_rockchip_unbind(struct device *dev, struct device
> *master,
> void *data)
>  {
> +   drm_encoder_cleanup(...);
> return dw_hdmi_unbind(dev, master, data);
>  }

That'a a reasonable suggestion in theory.  ...but we run into the same
problem I've run into before with the strange relationship between
dw_hdmi and its descendants.

Specifically:

* "struct dw_hdmi", which has a pointer to encoder, is private to dw-hdmi.c

* We could get the encoder if we had a pointer to the "struct
rockchip_hdmi", but there's no way to get that.  You would _think_ you
could get it back using platform_get_drvdata() because it was stashed
with platform_set_drvdata().  ...but you'd be wrong.  The
platform_set_drvdata() is just there to fool you.  I believe when you
call dw_hdmi_bind() it clobbers your drvdata when it calls
dev_set_drvdata(dev, hdmi);


Said another way: taking your suggestion means we need to add some way
for dw_hdmi-rockchip.c to get a pointer to the encoder from a "struct
device".  We could (A) move the "struct dw_hdmi" definition to a
private header and allow dw_hdmi-rockchip.c to include it or we could
(B) add a dw_hdmi_get_encoder() API call that dw_hdmi-rockchip.c could
call.


If someone would let me know whether (A) or (B) is OK I'm happy to post a patch.


...or, of course, if I've made a mistake in all the above, feel free
to point it out.


-Doug

[Bug 94410] [radeonsi] Unreal engine 4 Segmentation fault

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

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

--- Comment #1 from Michel D�nzer  ---
Looks like UE4Editor overrides some C++ memory allocation APIs, which breaks
LLVM.

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

[Bug 113341] GPU Lockup on AMD Kaveri

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

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

--- Comment #6 from Michel Dänzer  ---
Any chance you could try if this also happens with LLVM 3.8 or even current
SVN/Git?

Does it always happen when starting a particular application?

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

[PATCH resend] PCI: QEMU top-level IDs for (sub)vendor & device

[Daniel Vetter]

On Mon, Mar 07, 2016 at 12:09:51AM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 06, 2016 at 10:02:30PM +, Robin H. Johnson wrote:
> > Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
> > constants scattered in the kernel already used to detect QEMU.
> > 
> > They are defined in the QEMU codebase per docs/specs/pci-ids.txt.
> > 
> > Signed-off-by: Robin H. Johnson 
> > Reviewed-by: Takashi Iwai 
> > Reviewed-by: Gerd Hoffmann 
> > ---
> 
> Acked-by: Michael S. Tsirkin 
> 
> PCI tree seems to make the most sense.
> Bjorn, can you merge this please?

Yeah, ack for merging through pci.

Acked-by: Daniel Vetter 
-Daniel

> 
> > This change prompted by a near-miss in the review of recent change:
> > 'drm/i915: refine qemu south bridge detection'
> > 
> > This patch was previously sent to LKML 25 Jan 2016; and got some
> > reviews, but otherwise slipped through the cracks.
> > 
> > ---
> >  drivers/gpu/drm/bochs/bochs_drv.c   | 4 ++--
> >  drivers/gpu/drm/cirrus/cirrus_drv.c | 5 +++--
> >  drivers/virtio/virtio_pci_common.c  | 2 +-
> >  include/linux/pci_ids.h | 4 
> >  sound/pci/intel8x0.c| 4 ++--
> >  5 files changed, 12 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
> > b/drivers/gpu/drm/bochs/bochs_drv.c
> > index 7f1a360..b332b4d3 100644
> > --- a/drivers/gpu/drm/bochs/bochs_drv.c
> > +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> > @@ -182,8 +182,8 @@ static const struct pci_device_id bochs_pci_tbl[] = {
> > {
> > .vendor  = 0x1234,
> > .device  = 0x,
> > -   .subvendor   = 0x1af4,
> > -   .subdevice   = 0x1100,
> > +   .subvendor   = PCI_SUBVENDOR_ID_REDHAT_QUMRANET,
> > +   .subdevice   = PCI_SUBDEVICE_ID_QEMU,
> > .driver_data = BOCHS_QEMU_STDVGA,
> > },
> > {
> > diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
> > b/drivers/gpu/drm/cirrus/cirrus_drv.c
> > index b1619e2..7bc394e 100644
> > --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> > +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> > @@ -33,8 +33,9 @@ static struct drm_driver driver;
> >  
> >  /* only bind to the cirrus chip in qemu */
> >  static const struct pci_device_id pciidlist[] = {
> > -   { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
> > - 0, 0 },
> > +   { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446,
> > + PCI_SUBVENDOR_ID_REDHAT_QUMRANET, PCI_SUBDEVICE_ID_QEMU,
> > + 0, 0, 0 },
> > { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, PCI_VENDOR_ID_XEN,
> >   0x0001, 0, 0, 0 },
> > {0,}
> > diff --git a/drivers/virtio/virtio_pci_common.c 
> > b/drivers/virtio/virtio_pci_common.c
> > index 36205c2..127dfe4 100644
> > --- a/drivers/virtio/virtio_pci_common.c
> > +++ b/drivers/virtio/virtio_pci_common.c
> > @@ -467,7 +467,7 @@ static const struct dev_pm_ops virtio_pci_pm_ops = {
> >  
> >  /* Qumranet donated their vendor ID for devices 0x1000 thru 0x10FF. */
> >  static const struct pci_device_id virtio_pci_id_table[] = {
> > -   { PCI_DEVICE(0x1af4, PCI_ANY_ID) },
> > +   { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
> > { 0 }
> >  };
> >  
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 37f05cb..6d249d3 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2506,6 +2506,10 @@
> >  
> >  #define PCI_VENDOR_ID_AZWAVE   0x1a3b
> >  
> > +#define PCI_VENDOR_ID_REDHAT_QUMRANET0x1af4
> > +#define PCI_SUBVENDOR_ID_REDHAT_QUMRANET 0x1af4
> > +#define PCI_SUBDEVICE_ID_QEMU0x1100
> > +
> >  #define PCI_VENDOR_ID_ASMEDIA  0x1b21
> >  
> >  #define PCI_VENDOR_ID_CIRCUITCO0x1cc8
> > diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c
> > index 42bcbac..12c2c18 100644
> > --- a/sound/pci/intel8x0.c
> > +++ b/sound/pci/intel8x0.c
> > @@ -2980,8 +2980,8 @@ static int snd_intel8x0_inside_vm(struct pci_dev *pci)
> > goto fini;
> >  
> > /* check for known (emulated) devices */
> > -   if (pci->subsystem_vendor == 0x1af4 &&
> > -   pci->subsystem_device == 0x1100) {
> > +   if (pci->subsystem_vendor == PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
> > +   pci->subsystem_device == PCI_SUBDEVICE_ID_QEMU) {
> > /* KVM emulated sound, PCI SSID: 1af4:1100 */
> > msg = "enable KVM";
> > } else if (pci->subsystem_vendor == 0x1ab8) {
> > -- 
> > 2.3.0
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Linux 4.4.4 [regression]

[Linus Torvalds]

On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz  wrote:
>
> This same problem with X does happen in 4.5-rc7. And removing the line
> introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 makes X go again 
> on
> my laptop.

Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainline.

Dave, Alex: that commit makes Jörg-Volker's HP Pavilion dv7 with
hybrid graphics (AMD HD 4200 - AMD 5400) unable to run X. No
suspend/resume in sight, just starting X hangs.

I'd guess it's the "radeon_switcheroo_set_state()" craziness (based on
that hybrid graphics thing), but we need to do something since this is
a regression.

Just revert for now? Or do you have other suggestions for Jörg-Volker to test?

Maybe that call to drm_helper_hpd_irq_event() should be purely in the
real resume path?

Or maybe there is something that the switcheroo code does that just
interacts badly with the code in drm_helper_hpd_irq_event()? Deadlock
on mode_config.mutex or something?

I suspect we just need to revert, but if somebody who knows the code
sees some obvious fix, holler quickly, please.

Linus

Re: [PATCH] MAINTAINERS: Remove Terje Bergström as Tegra DRM maintainer

[Terje Bergstrom]

On 03/04/2016 03:58 AM, Thierry Reding wrote:
> From: Thierry Reding 
>
> Terje doesn't work on host1x anymore and doesn't have the time to help
> maintain the host1x and related drivers.
>
> Signed-off-by: Thierry Reding 
> ---
>   MAINTAINERS | 1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4a4edae9d2aa..d2a2864616e0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3844,7 +3844,6 @@ F:  include/drm/gma500*
>   
>   DRM DRIVERS FOR NVIDIA TEGRA
>   M:  Thierry Reding 
> -M:   Terje Bergström 
>   L:  dri-devel at lists.freedesktop.org
>   L:  linux-tegra at vger.kernel.org
>   T:  git git://anongit.freedesktop.org/tegra/linux.git

Acked-by: Terje Bergstrom 

Terje

[Bug 113861] [radeon] Xorg fatal freeze upon startx

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

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

--- Comment #2 from centuryplague at yandex.com ---
"It is not happening on 4.4.3 from distribution (but pure vanilla not tried)."
(but note 4.4.2 was tried which was vanilla + grsec, and had no problems... so
likely a change in 4.4.4 exactly triggers this bug)

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

[Bug 113861] [radeon] Xorg fatal freeze upon startx

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

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

--- Comment #1 from 3db5to+dsqmzpq58ju3k at sharklasers.com ---
Note there are NO Xorg.0.log produced, full freeze.

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

[Bug 113861] New: [radeon] Xorg fatal freeze upon startx

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

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

Bug ID: 113861
   Summary: [radeon] Xorg fatal freeze upon startx
   Product: Drivers
   Version: 2.5
Kernel Version: 4.4.4, 4.1.18 LTS
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: 3db5to+dsqmzpq58ju3k at sharklasers.com
Regression: No

Source of bug report:
https://bugs.archlinux.org/task/48468
https://bbs.archlinux.org/viewtopic.php?id=209576

When startx is used to start Xorg on an Arch system booted to command line with
radeon module, Xorg process is fully frozen and cannot be killed or terminated,
with message:
"waiting for X server to begin accepting connections...
...
..."
etc.
(CTRL-C 500 times to stop the polling, Xorg wrapper is unresponsive to kill -9)

This is happening on both 4.1.18 LTS and 4.4.4 (latter is vanilla + grsec). It
is not happening on 4.4.3 from distribution (but pure vanilla not tried).

Does not occur if radeon is blacklisted and VESA used instead.

Two reports so far. 
Mine is switchable :
[AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]
[AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M]
Forum user:
[AMD/ATI] Mars [Radeon HD 8730M]
... (see link)

Forum user recorded a stack trace (from his link
https://gist.github.com/Bernolt/ae162d69444f9937610d):

[] rpm_resume+0x171/0x660
[] __pm_runtime_resume+0x3f/0x60
[] radeon_dp_detect+0x64/0x2e0 [radeon]
[] drm_helper_hpd_irq_event+0xaa/0x140 [drm_kms_helper]
[] radeon_resume_kms+0x22c/0x420 [radeon]
[] radeon_pmops_runtime_resume+0x73/0xb0 [radeon]
[] pci_pm_runtime_resume+0x7f/0xc0
[] vga_switcheroo_runtime_resume+0x39/0x40
[] __rpm_callback+0x34/0x90
[] rpm_callback+0x28/0x90
[] rpm_resume+0x459/0x660
[] __pm_runtime_resume+0x3f/0x60
[] radeon_driver_open_kms+0x36/0x1d0 [radeon]
[] drm_open+0x1af/0x4c0 [drm]
[] drm_stub_open+0xa9/0x120 [drm]
[] chrdev_open+0xb6/0x1b0
[] do_dentry_open+0x227/0x330
[] vfs_open+0x56/0x60
[] do_last.isra.11+0x344/0xf50
[] path_openat+0x91/0x670
[] do_filp_open+0x49/0xd0
[] do_sys_open+0x14d/0x250
[] SyS_open+0x1e/0x20
[] system_call_fastpath+0x12/0x71
[] 0x

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

[Bug 94242] [radeonsi] Crash while running Fedora mock tool for prompting root (gtksu)

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

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

Ilia Mirkin  changed:

   What|Removed |Added

 Attachment #121931|text/plain  |application/octet-stream
  mime type||

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

[Bug 94412] Trine 3 misrender

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

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

--- Comment #3 from Michel D�nzer  ---
Please submit the patch to the mesa-dev mailing list for review, adding

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

to the Git commit log.

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

[PATCH resend] PCI: QEMU top-level IDs for (sub)vendor & device

[Michael S. Tsirkin]

On Sun, Mar 06, 2016 at 10:02:30PM +, Robin H. Johnson wrote:
> Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
> constants scattered in the kernel already used to detect QEMU.
> 
> They are defined in the QEMU codebase per docs/specs/pci-ids.txt.
> 
> Signed-off-by: Robin H. Johnson 
> Reviewed-by: Takashi Iwai 
> Reviewed-by: Gerd Hoffmann 
> ---

Acked-by: Michael S. Tsirkin 

PCI tree seems to make the most sense.
Bjorn, can you merge this please?

> This change prompted by a near-miss in the review of recent change:
> 'drm/i915: refine qemu south bridge detection'
> 
> This patch was previously sent to LKML 25 Jan 2016; and got some
> reviews, but otherwise slipped through the cracks.
> 
> ---
>  drivers/gpu/drm/bochs/bochs_drv.c   | 4 ++--
>  drivers/gpu/drm/cirrus/cirrus_drv.c | 5 +++--
>  drivers/virtio/virtio_pci_common.c  | 2 +-
>  include/linux/pci_ids.h | 4 
>  sound/pci/intel8x0.c| 4 ++--
>  5 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index 7f1a360..b332b4d3 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -182,8 +182,8 @@ static const struct pci_device_id bochs_pci_tbl[] = {
>   {
>   .vendor  = 0x1234,
>   .device  = 0x,
> - .subvendor   = 0x1af4,
> - .subdevice   = 0x1100,
> + .subvendor   = PCI_SUBVENDOR_ID_REDHAT_QUMRANET,
> + .subdevice   = PCI_SUBDEVICE_ID_QEMU,
>   .driver_data = BOCHS_QEMU_STDVGA,
>   },
>   {
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
> b/drivers/gpu/drm/cirrus/cirrus_drv.c
> index b1619e2..7bc394e 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> @@ -33,8 +33,9 @@ static struct drm_driver driver;
>  
>  /* only bind to the cirrus chip in qemu */
>  static const struct pci_device_id pciidlist[] = {
> - { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
> -   0, 0 },
> + { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446,
> +   PCI_SUBVENDOR_ID_REDHAT_QUMRANET, PCI_SUBDEVICE_ID_QEMU,
> +   0, 0, 0 },
>   { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, PCI_VENDOR_ID_XEN,
> 0x0001, 0, 0, 0 },
>   {0,}
> diff --git a/drivers/virtio/virtio_pci_common.c 
> b/drivers/virtio/virtio_pci_common.c
> index 36205c2..127dfe4 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -467,7 +467,7 @@ static const struct dev_pm_ops virtio_pci_pm_ops = {
>  
>  /* Qumranet donated their vendor ID for devices 0x1000 thru 0x10FF. */
>  static const struct pci_device_id virtio_pci_id_table[] = {
> - { PCI_DEVICE(0x1af4, PCI_ANY_ID) },
> + { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
>   { 0 }
>  };
>  
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 37f05cb..6d249d3 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2506,6 +2506,10 @@
>  
>  #define PCI_VENDOR_ID_AZWAVE 0x1a3b
>  
> +#define PCI_VENDOR_ID_REDHAT_QUMRANET0x1af4
> +#define PCI_SUBVENDOR_ID_REDHAT_QUMRANET 0x1af4
> +#define PCI_SUBDEVICE_ID_QEMU0x1100
> +
>  #define PCI_VENDOR_ID_ASMEDIA0x1b21
>  
>  #define PCI_VENDOR_ID_CIRCUITCO  0x1cc8
> diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c
> index 42bcbac..12c2c18 100644
> --- a/sound/pci/intel8x0.c
> +++ b/sound/pci/intel8x0.c
> @@ -2980,8 +2980,8 @@ static int snd_intel8x0_inside_vm(struct pci_dev *pci)
>   goto fini;
>  
>   /* check for known (emulated) devices */
> - if (pci->subsystem_vendor == 0x1af4 &&
> - pci->subsystem_device == 0x1100) {
> + if (pci->subsystem_vendor == PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
> + pci->subsystem_device == PCI_SUBDEVICE_ID_QEMU) {
>   /* KVM emulated sound, PCI SSID: 1af4:1100 */
>   msg = "enable KVM";
>   } else if (pci->subsystem_vendor == 0x1ab8) {
> -- 
> 2.3.0