lp:~ubuntu-kernel-test/ubuntu/+source/linux/+git/mirror-drm-intel

Get this repository:
git clone https://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mirror-drm-intel
Members of Ubuntu Kernel Test can upload to this repository. Log in for directions.

Updating repository...

Launchpad is processing new changes to this repository which will be available shortly. Reload to see the changes.

Branches

Name Last Modified Last Commit
drm-intel-next-queued 2020-10-20 18:12:52 UTC 2 hours ago
drm/i915: Sort ICL PCI IDs

Author: Ville Syrjälä
Author Date: 2020-07-16 17:21:05 UTC

drm/i915: Sort ICL PCI IDs

Sort the ICL PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-14-ville.syrjala@linux.intel.com
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>

drm-intel-gt-next 2020-10-20 09:16:54 UTC 11 hours ago
drm/i915: Exclude low pages (128KiB) of stolen from use

Author: Chris Wilson
Author Date: 2020-10-19 16:50:05 UTC

drm/i915: Exclude low pages (128KiB) of stolen from use

The GPU is trashing the low pages of its reserved memory upon reset. If
we are using this memory for ringbuffers, then we will dutiful resubmit
the trashed rings after the reset causing further resets, and worse. We
must exclude this range from our own use. The value of 128KiB was found
by empirical measurement (and verified now with a selftest) on gen9.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019165005.18128-2-chris@chris-wilson.co.uk

for-linux-next 2020-10-19 18:32:31 UTC 2020-10-19
drm/i915/gt: Wait for CSB entries on Tigerlake

Author: Chris Wilson
Author Date: 2020-09-15 13:49:21 UTC

drm/i915/gt: Wait for CSB entries on Tigerlake

On Tigerlake, we are seeing a repeat of commit d8f505311717 ("drm/i915/icl:
Forcibly evict stale csb entries") where, presumably, due to a missing
Global Observation Point synchronisation, the write pointer of the CSB
ringbuffer is updated _prior_ to the contents of the ringbuffer. That is
we see the GPU report more context-switch entries for us to parse, but
those entries have not been written, leading us to process stale events,
and eventually report a hung GPU.

However, this effect appears to be much more severe than we previously
saw on Icelake (though it might be best if we try the same approach
there as well and measure), and Bruce suggested the good idea of resetting
the CSB entry after use so that we can detect when it has been updated by
the GPU. By instrumenting how long that may be, we can set a reliable
upper bound for how long we should wait for:

    513 late, avg of 61 retries (590 ns), max of 1061 retries (10099 ns)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2045
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
References: HSDES#22011327657, HSDES#1508287568
Suggested-by: Bruce Chang <yu.bruce.chang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org # v5.4
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200915134923.30088-2-chris@chris-wilson.co.uk
(cherry picked from commit 233c1ae3c83f21046c6c4083da904163ece8f110)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm-intel-next-fixes 2020-10-19 18:32:31 UTC 2020-10-19
drm/i915/gt: Wait for CSB entries on Tigerlake

Author: Chris Wilson
Author Date: 2020-09-15 13:49:21 UTC

drm/i915/gt: Wait for CSB entries on Tigerlake

On Tigerlake, we are seeing a repeat of commit d8f505311717 ("drm/i915/icl:
Forcibly evict stale csb entries") where, presumably, due to a missing
Global Observation Point synchronisation, the write pointer of the CSB
ringbuffer is updated _prior_ to the contents of the ringbuffer. That is
we see the GPU report more context-switch entries for us to parse, but
those entries have not been written, leading us to process stale events,
and eventually report a hung GPU.

However, this effect appears to be much more severe than we previously
saw on Icelake (though it might be best if we try the same approach
there as well and measure), and Bruce suggested the good idea of resetting
the CSB entry after use so that we can detect when it has been updated by
the GPU. By instrumenting how long that may be, we can set a reliable
upper bound for how long we should wait for:

    513 late, avg of 61 retries (590 ns), max of 1061 retries (10099 ns)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2045
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
References: HSDES#22011327657, HSDES#1508287568
Suggested-by: Bruce Chang <yu.bruce.chang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org # v5.4
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200915134923.30088-2-chris@chris-wilson.co.uk
(cherry picked from commit 233c1ae3c83f21046c6c4083da904163ece8f110)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

for-linux-next-fixes 2020-10-11 21:15:50 UTC 2020-10-11
Linux 5.9

Author: Linus Torvalds
Author Date: 2020-10-11 21:15:50 UTC

Linux 5.9

drm-intel-fixes 2020-10-11 21:15:50 UTC 2020-10-11
Linux 5.9

Author: Linus Torvalds
Author Date: 2020-10-11 21:15:50 UTC

Linux 5.9

topic/core-for-CI 2020-09-28 10:47:57 UTC 2020-09-28
mm: do not rely on mm == current->mm in __get_user_pages_locked

Author: Jason A. Donenfeld
Author Date: 2020-09-28 10:35:07 UTC

mm: do not rely on mm == current->mm in __get_user_pages_locked

It seems likely this block was pasted from internal_get_user_pages_fast,
which is not passed an mm struct and therefore uses current's. But
__get_user_pages_locked is passed an explicit mm, and current->mm is not
always valid. This was hit when being called from i915, which uses:

  pin_user_pages_remote->
    __get_user_pages_remote->
      __gup_longterm_locked->
        __get_user_pages_locked

Before, this would lead to an OOPS:

  BUG: kernel NULL pointer dereference, address: 0000000000000064
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 0 P4D 0
  Oops: 0002 [#1] SMP
  CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
  Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
  Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
  RIP: 0010:__get_user_pages_remote+0xd7/0x310
  Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
  RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
  RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
  RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
  RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
  R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
  R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
  FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
  CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
   process_one_work+0x1ca/0x390
   worker_thread+0x48/0x3c0
   ? rescuer_thread+0x3d0/0x3d0
   kthread+0x114/0x130
   ? kthread_create_worker_on_cpu+0x40/0x40
   ret_from_fork+0x1f/0x30
  CR2: 0000000000000064

This commit fixes the problem by using the mm pointer passed to the
function rather than the bogus one in current.

Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

drm-intel-next 2020-09-17 20:43:57 UTC 2020-09-17
drm/i915: Update DRIVER_DATE to 20200917

Author: Rodrigo Vivi
Author Date: 2020-09-17 20:43:57 UTC

drm/i915: Update DRIVER_DATE to 20200917

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

topic/drm-intel-gem-next 2020-09-03 13:44:14 UTC 2020-09-03
drm/i915: fix regression leading to display audio probe failure on GLK

Author: Kai Vehmanen
Author Date: 2020-09-01 15:10:36 UTC

drm/i915: fix regression leading to display audio probe failure on GLK

In commit 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking
to separate function") the order of force_min_cdclk_changed check and
intel_modeset_checks(), was reversed. This broke the mechanism to
immediately force a new CDCLK minimum, and lead to driver probe
errors for display audio on GLK platform with 5.9-rc1 kernel. Fix
the issue by moving intel_modeset_checks() call later.

[vsyrjala: It also broke the ability of planes to bump up the cdclk
and thus could lead to underruns when eg. flipping from 32bpp to
64bpp framebuffer. To be clear, we still compute the new cdclk
correctly but fail to actually program it to the hardware due to
intel_set_cdclk_{pre,post}_plane_update() not getting called on
account of state->modeset==false.]

Fixes: 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking to separate function")
BugLink: https://github.com/thesofproject/linux/issues/2410
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200901151036.1312357-1-kai.vehmanen@linux.intel.com

topic/drm-warn 2020-01-22 14:17:32 UTC 2020-01-22
drm/print: introduce new struct drm_device based WARN* macros

Author: Pankaj Bharadiya
Author Date: 2020-01-15 03:44:45 UTC

drm/print: introduce new struct drm_device based WARN* macros

Add new struct drm_device based WARN* macros. These are modeled after
the core kernel device based WARN* macros. These would be preferred
over the regular WARN* macros, where possible.

These macros include device information in the backtrace, so we know
what device the warnings originate from.

Knowing the device specific information in the backtrace would be
helpful in development all around.

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-2-pankaj.laxminarayan.bharadiya@intel.com

topic/drm-mipi-dsi-dsc-updates 2019-11-07 13:00:16 UTC 2019-11-07
drm/dsi: add helpers for DSI compression mode and PPS packets

Author: Jani Nikula
Author Date: 2019-10-28 15:00:47 UTC

drm/dsi: add helpers for DSI compression mode and PPS packets

Add helper functions for sending the DSI compression mode and picture
parameter set data type packets. For the time being, limit the support
to using VESA DSC 1.1 and the default PPS. This may need updating if the
need arises for proprietary compression or non-default PPS, however keep
it simple for starters.

v2: Add missing EXPORT_SYMBOL

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028150047.22048-5-jani.nikula@intel.com

topic/mei-hdcp 2019-02-25 16:03:01 UTC 2019-02-25
misc/mei/hdcp: Component framework for I915 Interface

Author: Ramalingam C
Author Date: 2019-02-21 18:12:09 UTC

misc/mei/hdcp: Component framework for I915 Interface

Mei hdcp driver is designed as component slave for the I915 component
master.

v2: Rebased.
v3:
  Notifier chain is adopted for cldev state update [Tomas]
v4:
  Made static dummy functions as inline in mei_hdcp.h
  API for polling client device status
  IS_ENABLED used in header, for config status for mei_hdcp.
v5:
  Replacing the notifier with component framework. [Daniel]
v6:
  Rebased on the I915 comp master redesign.
v7:
  mei_hdcp_component_registered is made static [Uma]
  Need for global static variable mei_cldev is removed.
v8:
  master comp is added to be matched with i915 subcomponent [daniel]
v9:
  only comp_master is set and retrieved as driver_data [Daniel]
  Reviewed-by Daniel.
v10:
  small corrections at probe [Tomas]
v11:
  bind and unbind logs are made as debug logs [Tomas]
  cldev_enable failure is handled [Tomas]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1550772730-23280-16-git-send-email-ramalingam.c@intel.com

topic/component-typed 2019-02-08 15:58:59 UTC 2019-02-08
i915/snd_hdac: I915 subcomponent for the snd_hdac

Author: Daniel Vetter
Author Date: 2019-02-07 23:27:59 UTC

i915/snd_hdac: I915 subcomponent for the snd_hdac

Since we need multiple components for I915 for different purposes
(Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
by the previous patch (mentioned below).

 Author: Daniel Vetter <daniel.vetter@ffwll.ch>
 Date: Mon Jan 28 17:08:20 2019 +0530

     components: multiple components for a device

Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by-by: Ramalingam C <ramalinagm.c@intel.com> (commit message)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (code)
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Russell King <rmk+kernel@arm.linux.org.uk>
cc: Rafael J. Wysocki <rafael@kernel.org>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
cc: Jani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190207232759.14553-4-daniel.vetter@ffwll.ch

topic/drmp-cleanup 2019-01-02 09:38:08 UTC 2019-01-02
drm: forward declare struct drm_file in drm_syncobj.h

Author: Jani Nikula
Author Date: 2018-12-28 08:28:15 UTC

drm: forward declare struct drm_file in drm_syncobj.h

drm_syncobj.h uses struct drm_file pointers, forward declare struct
drm_file to make the header self-contained. This prepares for dropping
drmP.h from files including drm_syncobj.h.

Switch from "" to <> includes while at it.

v2: forward declare instead of including drm_file.h (Daniel)

[Updated commit message per Laurent's review while applying.]

Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181228082815.10797-1-jani.nikula@intel.com

drm-intel-testing 2018-11-22 14:50:47 UTC 2018-11-22
drm-tip: 2018y-11m-22d-14h-49m-31s UTC integration manifest

Author: Jani Nikula
Author Date: 2018-11-22 14:50:47 UTC

drm-tip: 2018y-11m-22d-14h-49m-31s UTC integration manifest

maintainer-tools 2018-02-07 10:05:39 UTC 2018-02-07
dim: Move maintainer-tools branch to drm-tip

Author: Daniel Vetter
Author Date: 2018-02-02 10:31:15 UTC

dim: Move maintainer-tools branch to drm-tip

Originally I wanted to move it to a completely stand-alone
maintainer-tools.git repo. But that has the problem that we need to
keep track of, and update, yet another remote. Easy way out it to
simply stuff the maintainer-tools branch into drm-tip.

The auto-upgrade hack is a bit gross, but shouldn't really cause
overhead. I've also pushed out the latest maintainer-tools (without
this patch) to drm-tip.git to make sure the patch can be tested.

The neat thing here is that this allows us to finally remove
drm-intel url hardcoding from dim.

v2: Update the docs, I've forgotten about those (Jani)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm-intel/drm-intel-fixes 2017-11-27 00:01:47 UTC 2017-11-27
Linux 4.15-rc1

Author: Linus Torvalds
Author Date: 2017-11-27 00:01:47 UTC

Linux 4.15-rc1

rerere-cache 2017-10-24 17:29:54 UTC 2017-10-24
2017y-10m-24d-17h-29m-13s UTC: drm-tip rerere cache update

Author: Rodrigo Vivi
Author Date: 2017-10-24 17:29:54 UTC

2017y-10m-24d-17h-29m-13s UTC: drm-tip rerere cache update

git version 2.13.5

drm-intel-nightly 2017-10-19 11:12:20 UTC 2017-10-19
drm-tip: 2017y-10m-19d-11h-11m-53s UTC integration manifest

Author: Daniel Vetter
Author Date: 2017-10-19 11:12:20 UTC

drm-tip: 2017y-10m-19d-11h-11m-53s UTC integration manifest

drm-amd/drm-misc-next 2017-09-27 08:28:50 UTC 2017-09-27
drm/amd: DC pull request review

Author: Daniel Vetter
Author Date: 2017-09-27 08:03:59 UTC

drm/amd: DC pull request review

Ok, here's one more attempt at scrolling through 130k diff.

Overall verdict from me is that DC is big project, and like any big
project it's never done. So at least for me the goal isn't to make
things perfect, becaue if that's the hoop to jump through we wouldn't
have any gpu drivers at all. More important is whether merging a new
driver base will benefit the overall subsystem, and here this
primarily means whether the DC team understand how upstream works and
is designed, and whether the code is largely aligned.

Looking back over the last two years I think that's the case, so

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

for merging this pull.

While scrolling through the pull I spotted a bunch more things that
should be refactored, but most of these will be a real pain while DC
is out of tree, and much easier in tree since in many of these areas
the in-tree helpers aren't up to snuff yet for what DC needs. That
kind of work is best done when there's one tree with everything
integrated.

That's also why I think we should merge DC into drm-next directly, so
we can get started on the integration polish right away. That has a
bit higher risk of Linus having a spazz, so here's my recommendation
for merging:

- There's a few additions to drm_dp_helper.h sprinkled all over the
  pull. I think those should be put into a patch of it's own, and
  merged first. No need to rebase DC, git merge will dtrt.

- dm_alloc/realloc/free is something Dave Airlie noticed, and I agree
  it's an easy red flag that might upset Linus. cocci can fix this
  easy, so no real problem I think to patch up in one big patch (I
  thought we've had a "remove malloc wrappers" todo item in the very
  first review, apparently there was more than one such wrapper).

- The history is huge, but AMD folks want to keep it if possible, and
  I see the value in that. Would be good to get an ack from Linus for
  that (but shouldn't be an issue, not the first time we've merged the
  full history of out-of-tree work).

Short&longer term TODO items are still tracked, might be a good idea
to integrate those the overall drm todo in our gpu documentation.

So in a way this is kinda like staging, except not with the horribly
broken process of having an entirely separate tree for staging drivers
which just makes refactoring needlessly painful (which defeats the
point of staging really). So staging-within-the-subsystem. We've had
that before, with early nouveau.

And yes some of the files are utterly horrible to read and not
anything close to kernel coding style standards. But that's the point,
they're essentially gospel from hw engineers that happens to be
parseable by gcc.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

topic/e1000e-fix 2017-05-30 07:47:28 UTC 2017-05-30
e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

Author: Chris Wilson
Author Date: 2017-02-17 12:30:51 UTC

e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

An error during suspend (e100e_pm_suspend),

[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 00000011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[ 430.955458] PM: Device 0000:00:19.0 failed to suspend async: error -2
[ 430.955581] PM: Some devices failed to suspend, or early wake event detected
[ 430.957709] ACPI : EC: event unblocked

lead to complete failure:

[ 432.585002] ------------[ cut here ]------------
[ 432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 __free_irq+0x9f/0x280
[ 432.585015] Trying to free already-free IRQ 20
[ 432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci i915 mmc_core e1000e ptp pps_core prime_numbers
[ 432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U 4.10.0-rc8-CI-Patchwork_3870+ #1
[ 432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012
[ 432.585050] Workqueue: events_unbound async_run_entry_fn
[ 432.585051] Call Trace:
[ 432.585058] dump_stack+0x67/0x92
[ 432.585062] __warn+0xc6/0xe0
[ 432.585065] warn_slowpath_fmt+0x4a/0x50
[ 432.585070] ? _raw_spin_lock_irqsave+0x49/0x60
[ 432.585072] __free_irq+0x9f/0x280
[ 432.585075] free_irq+0x34/0x80
[ 432.585089] e1000_free_irq+0x65/0x70 [e1000e]
[ 432.585098] e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[ 432.585106] e1000e_pm_suspend+0x21/0x30 [e1000e]
[ 432.585113] pci_pm_suspend+0x71/0x140
[ 432.585118] dpm_run_callback+0x6f/0x330
[ 432.585122] ? pci_pm_freeze+0xe0/0xe0
[ 432.585125] __device_suspend+0xea/0x330
[ 432.585128] async_suspend+0x1a/0x90
[ 432.585132] async_run_entry_fn+0x34/0x160
[ 432.585137] process_one_work+0x1f4/0x6d0
[ 432.585140] ? process_one_work+0x16e/0x6d0
[ 432.585143] worker_thread+0x49/0x4a0
[ 432.585145] kthread+0x107/0x140
[ 432.585148] ? process_one_work+0x6d0/0x6d0
[ 432.585150] ? kthread_create_on_node+0x40/0x40
[ 432.585154] ret_from_fork+0x2e/0x40
[ 432.585156] ---[ end trace 6712df7f8c4b9124 ]---

The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.

Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Dave Ertman <davidx.m.ertman@intel.com>
Cc: Bruce Allan <bruce.w.allan@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

topic/dp-quirks 2017-05-29 10:43:47 UTC 2017-05-29
drm/i915: Detect USB-C specific dongles before reducing M and N

Author: Jani Nikula
Author Date: 2017-05-18 11:10:25 UTC

drm/i915: Detect USB-C specific dongles before reducing M and N

The Analogix 7737 DP to HDMI converter requires reduced M and N values
when to operate correctly at HBR2. We tried to reduce the M/N values for
all devices in commit 9a86cda07af2 ("drm/i915/dp: reduce link M/N
parameters"), but that regressed some other sinks. Detect this IC by its
OUI value of 0x0022B9 via the DPCD quirk list, and only reduce the M/N
values for that.

v2 by Jani: Rebased on the DP quirk database

v3 by Jani: Rebased on the reworked DP quirk database

v4 by Jani: Improve commit message (Daniel)

Fixes: 9a86cda07af2 ("drm/i915/dp: reduce link M/N parameters")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100755
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/2d2e30f8f47d3f28c9b74ca2612336a54585c3ec.1495105635.git.jani.nikula@intel.com

topic/dim-testing 2017-05-22 02:30:23 UTC 2017-05-22
Linux 4.12-rc2

Author: Linus Torvalds
Author Date: 2017-05-22 02:30:23 UTC

Linux 4.12-rc2

topic/designware-baytrail 2017-03-02 14:46:37 UTC 2017-03-02
drm/i915: Listen for PMIC bus access notifications

Author: Hans de Goede
Author Date: 2017-02-10 10:28:02 UTC

drm/i915: Listen for PMIC bus access notifications

Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
the bus is accessed to avoid needing to do any forcewakes, which need
PMIC bus access, while the PMIC bus is busy:

This fixes errors like these showing up in dmesg, usually followed
by a gfx or system freeze:

[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
[drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake ack request.
i2c_designware 808622C1:06: punit semaphore timed out, resetting
i2c_designware 808622C1:06: PUNIT SEM: 2
i2c_designware 808622C1:06: couldn't acquire bus ownership

Downside of this approach is that it causes wakeups whenever the PMIC
bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
to go idle when we hit a race, as forcewakes may be done from interrupt
handlers where we cannot sleep to wait for the i2c PMIC bus access to
finish.

Note that the notifications and thus the wakeups will only happen on
baytrail / cherrytrail devices using PMICs with a shared i2c bus for
P-Unit and host PMIC access (i2c busses with a _SEM method in their
APCI node), e.g. an axp288 PMIC.

I plan to write some patches for drivers accessing the PMIC bus to
limit their bus accesses to a bare minimum (e.g. cache registers, do not
update battery level more often then 4 times a minute), to limit the
amount of wakeups.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: tagorereddy <tagore.chandan@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Wiggle in conflicts.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

topic/vma-fix-for-4.10 2017-02-01 09:45:21 UTC 2017-02-01
drm/i915: Track pinned vma in intel_plane_state

Author: Chris Wilson
Author Date: 2017-01-31 09:21:31 UTC

drm/i915: Track pinned vma in intel_plane_state

With atomic plane states we are able to track an allocation right from
preparation, during use and through to the final free after being
swapped out for a new plane. We can couple the VMA we pin for the
framebuffer (and its rotation) to this lifetime and avoid all the clumsy
lookups in between.

v2: Remove residual vma on plane cleanup (Chris)
v3: Add a description for the vma destruction in
    intel_plane_destroy_state (Maarten)

References: https://bugs.freedesktop.org/show_bug.cgi?id=98829
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170116152131.18089-1-chris@chris-wilson.co.uk
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit be1e341513ca23b0668b7b0f26fa6e2ffc46ba20)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485854491-27389-3-git-send-email-maarten.lankhorst@linux.intel.com

topic/drm-misc 2016-11-24 08:57:15 UTC 2016-11-24
drm: bridge: add DesignWare HDMI I2S audio support

Author: Kuninori Morimoto
Author Date: 2016-11-08 01:00:57 UTC

drm: bridge: add DesignWare HDMI I2S audio support

Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.

Tested-by: Jose Abreu <joabreu@synopsys.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/8737j2bxba.wl%kuninori.morimoto.gx@renesas.com

topic/foo 2016-11-10 10:19:21 UTC 2016-11-10
Some garbage commit for testing.

Author: Daniel Vetter
Author Date: 2016-11-10 10:19:21 UTC

Some garbage commit for testing.

drm-misc 2016-10-17 07:07:31 UTC 2016-10-17
drm: Print device information again in debugfs

Author: Daniel Vetter
Author Date: 2016-10-13 14:11:03 UTC

drm: Print device information again in debugfs

I was a bit over-eager in my cleanup in

commit 95c081c17f284de50eaca60d4d55643a64d39019
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 21 10:54:12 2016 +0200

    drm: Move master pointer from drm_minor to drm_device

Noticed by Chris Wilson.

Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

topic/drm-fixes 2016-09-04 21:31:46 UTC 2016-09-04
Linux 4.8-rc5

Author: Linus Torvalds
Author Date: 2016-09-04 21:31:46 UTC

Linux 4.8-rc5

topic/sphinx-wip 2016-07-20 22:56:21 UTC 2016-07-20
Revert "doc/sphinx: Enable keep_warnings"

Author: Jonathan Corbet
Author Date: 2016-07-20 22:56:21 UTC

Revert "doc/sphinx: Enable keep_warnings"

This reverts commit 47d6d752b9e20dbe8a2acd22e887be81a6f39de9.

Commit f42ddca7bebc (doc-rst: kernel-doc directive, fix state machine
reporter) from Marcus Heiser provides a better fix, so this configuration
change is no longer needed.

topic/kbl-4.7-fixes 2016-07-18 16:46:19 UTC 2016-07-18
drm/i915/kbl: Introduce the first official DMC for Kabylake.

Author: Rodrigo Vivi
Author Date: 2016-04-26 21:59:51 UTC

drm/i915/kbl: Introduce the first official DMC for Kabylake.

Version 1.01.

This firmware is made for Kabylake platform so it doesn't
need the stepping workaround that we had before.

v2: Rebased on top of latest nightly with min version
    required change.
v3: With right CSR_VERSION (Patrik).

Cc: Christophe Prigent <christophe.prigent@intel.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461707991-15336-1-git-send-email-rodrigo.vivi@intel.com
(cherry picked from commit 4922d4919596219864686be1e70dcd92c685ec9f)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

topic/sphinx 2016-06-20 12:41:06 UTC 2016-06-20
Documentation: add gpu document converted from DocBook

Author: Jani Nikula
Author Date: 2016-05-30 16:31:12 UTC

Documentation: add gpu document converted from DocBook

$ cd Documentation/sphinx
$ ./tmplcvt ../DocBook/gpu.tmpl ../gpu.rst

This is for the topic/sphinx branch only. The DocBook gpu.tmpl remains
the master document for now.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

topic/lockless-gem-bo-freeing 2016-06-01 07:42:08 UTC 2016-06-01
drm/arcpgu: Use lockless gem BO free callback

Author: Daniel Vetter
Author Date: 2016-05-30 17:53:16 UTC

drm/arcpgu: Use lockless gem BO free callback

No dev->struct_mutex anywhere to be seen.

Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-25-git-send-email-daniel.vetter@ffwll.ch

topic/kerneldoc 2016-05-04 14:14:44 UTC 2016-05-04
drm: Enable markdown^Wasciidoc for gpu.tmpl

Author: Daniel Vetter
Author Date: 2015-11-25 10:35:52 UTC

drm: Enable markdown^Wasciidoc for gpu.tmpl

This enables asciidoc support for the gpu docbook.

Note that asciidoc is optional - all the kerneldoc comment layout
rules are the same, those bits landed in 4.4. It will simply not quite
look as pretty if you don't have it installed.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Thomas Wood <thomas.wood@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

topic/struct_mutex 2016-04-20 10:58:53 UTC 2016-04-20
drm/vma_manage: Drop has_offset

Author: Daniel Vetter
Author Date: 2016-03-30 09:40:52 UTC

drm/vma_manage: Drop has_offset

It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.

The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.

While at it add a note in the create_mmap_offset kerneldoc that
drivers must release it again. And then I also noticed that
drm_gem_object_release entirely lacks kerneldoc.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-14-git-send-email-daniel.vetter@ffwll.ch

topic/mode_fixup-optional 2016-03-04 17:16:56 UTC 2016-03-04
drm/ast: removed optional dummy crtc mode_fixup function.

Author: Carlos Palminha
Author Date: 2016-02-16 14:20:14 UTC

drm/ast: removed optional dummy crtc mode_fixup function.

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 <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/0f8f948babd93fce8523253b0f525446e2f565db.1455630967.git.palminha@synopsys.com

ci/daniels/tmp 2016-02-13 15:31:50 UTC 2016-02-13
WIP: VC4/RPI2 DRM

Author: Daniel Stone
Author Date: 2016-02-13 15:31:50 UTC

WIP: VC4/RPI2 DRM

topic/mst-fixes 2015-08-04 09:10:41 UTC 2015-08-04
drm/atomic-helpers: Make encoder picking more robust

Author: Daniel Vetter
Author Date: 2015-08-03 15:24:11 UTC

drm/atomic-helpers: Make encoder picking more robust

We've had a few issues with atomic where subtle bugs in the encoder
picking logic lead to accidental self-stealing of the encoder,
resulting in a NULL connector_state->crtc in update_connector_routing
and subsequent.

Linus applied some duct-tape for an mst regression in

commit 27667f4744fc5a0f3e50910e78740bac5670d18b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Jul 29 22:18:16 2015 -0700

    i915: temporary fix for DP MST docking station NULL pointer dereference

But that was incomplete (the code will still oops when debuggin is
enabled) and mangled the state even further. So instead WARN and bail
out as the more future-proof option.

Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

topic/connector-locking 2015-07-22 15:29:38 UTC 2015-07-22
drm: gc now dead mode_group code

Author: Daniel Vetter
Author Date: 2015-07-09 21:44:37 UTC

drm: gc now dead mode_group code

Two nice things here:
- drm_dev_register will truly register everything in the right order
  if the driver doesn't have a ->load callback. Before this we had to
  init the primary mode_group after the device nodes where already
  registered.

- Less things to keep track of when reworking the connector locking,
  yay!

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

topic/crc-pmic 2015-07-22 09:18:41 UTC 2015-07-22
mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled

Author: Shobhit Kumar
Author Date: 2015-07-22 08:31:44 UTC

mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled

This is needed as the CRC PMIC has support for Panel
enable/diable as gpio which needs 'gpiod_add_lookup_table'
and 'gpiod_remove_lookup_table' from gpiolib. This patch
can be squashed with below commit in topic/crc-pmic branch

    commit 61dd2ca2d44e493b050adbbb75bc50db11c367dd
    Author: Shobhit Kumar <shobhit.kumar@intel.com>
    Date: Fri Jun 26 14:32:05 2015 +0530

    mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO
    signal

    On some Intel SoC platforms, the panel enable/disable signals
    are controlled by CRC PMIC. Add those control as a new GPIO in a
    lookup table for gpio-crystalcove chip during CRC driver load

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

topic/atomic-conversion 2015-06-12 12:11:11 UTC 2015-06-12
drm/i915: Only enable cursor if it can be enabled.

Author: Maarten Lankhorst
Author Date: 2015-06-12 09:15:42 UTC

drm/i915: Only enable cursor if it can be enabled.

The cursor should only be enabled if it's visible. This fixes
igt/kms_cursor_crc, which may otherwise produce the following
warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3425 at drivers/gpu/drm/i915/intel_display.c:9995 intel_crtc_update_cursor+0x14c/0x4d0 [i915]()
Missing switch case (0) in i9xx_update_cursor
Modules linked in: i915
CPU: 0 PID: 3425 Comm: kms_cursor_crc Tainted: G W 4.1.0-rc7-patser+ #4079
Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
 ffffffffc01aad10 ffff8800b083faa8 ffffffff817f7827 0000000080000001
 ffff8800b083faf8 ffff8800b083fae8 ffffffff81084955 ffff8800b083fad8
 ffff8800c4931148 0000000001200000 ffff8800c48b0000 0000000000000000
Call Trace:
 [<ffffffff817f7827>] dump_stack+0x4f/0x7b
 [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0
 [<ffffffff810849d1>] warn_slowpath_fmt+0x41/0x50
 [<ffffffffc0139f2c>] intel_crtc_update_cursor+0x14c/0x4d0 [i915]
 [<ffffffffc01497f4>] __intel_set_mode+0x6c4/0x750 [i915]
 [<ffffffffc0150143>] intel_crtc_set_config+0x473/0x5c0 [i915]
 [<ffffffff81467da9>] drm_mode_set_config_internal+0x69/0x120
 [<ffffffff8146c1b9>] drm_mode_setcrtc+0x189/0x540
 [<ffffffff8145c7e0>] drm_ioctl+0x1a0/0x6a0
 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
 [<ffffffff811e9c28>] do_vfs_ioctl+0x2f8/0x530
 [<ffffffff810d0f7d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff812e7746>] ? selinux_file_ioctl+0x56/0x100
 [<ffffffff811e9ee1>] SyS_ioctl+0x81/0xa0
 [<ffffffff81801617>] system_call_fastpath+0x12/0x6f
---[ end trace abf0f71163290a96 ]---

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

topic/bxt-stage1 2015-04-09 13:57:57 UTC 2015-04-09
drm/i915/bxt: Support BXT in SSEU device status dump

Author: Jeff McGee
Author Date: 2015-04-04 01:13:18 UTC

drm/i915/bxt: Support BXT in SSEU device status dump

Modify the Gen9 SSEU device status logic to support Broxton.
Broxton reuses the Skylake power gate acknowledgment registers but
has at most 1 slice and 3 subslices. Broxton supports subslice
power gating within its single slice.

Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

topic/core-stuff 2015-01-29 11:50:03 UTC 2015-01-29
drm/irq: Don't disable vblank interrupts when already disabled

Author: Laurent Pinchart
Author Date: 2015-01-28 23:09:24 UTC

drm/irq: Don't disable vblank interrupts when already disabled

The .enable_vblank() operation is only called when vblank interrupts are
disabled, but no similar check exists when disabling vblank interrupts.
This leads to .disable_vblank() being called with vblank interrupts
already disabled and the device possibly runtime suspended. As the
operation is called with a spinlock held drivers can't runtime resume
the device there and thus must avoid touching device registers in that
case, requiring vblank refcounting.

As the DRM core tracks whether vblank interrupts are enabled just skip
the .disable_vblank() call when the interrupts are already disabled.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

topic/atomic-core 2015-01-27 09:02:52 UTC 2015-01-27
drm/atomic: Fix potential use of state after free

Author: Ander Conselvan de Oliveira
Author Date: 2015-01-23 07:27:59 UTC

drm/atomic: Fix potential use of state after free

The atomic helpers rely on drm_atomic_state_clear() to reset an atomic
state if a retry is needed due to the w/w mutexes. The subsequent calls
to drm_atomic_get_{crtc,plane,...}_state() would then return the stale
pointers in state->{crtc,plane,...}_states.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

144 of 44 results
This repository contains Public information 
Everyone can see this information.