From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Dave Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Intel Graphics <intel-gfx@lists.freedesktop.org>,
DRI <dri-devel@lists.freedesktop.org>
Cc: "Linux Next Mailing List" <linux-next@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: Re: linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Date: Fri, 8 Nov 2019 11:42:44 +1100 [thread overview]
Message-ID: <20191108114244.357c594f@canb.auug.org.au> (raw)
In-Reply-To: <20191031113315.4183cc7a@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]
Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Thu, 31 Oct 2019 11:33:15 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.h
>
> between commit:
>
> 59cd826fb5e7 ("drm/i915: Fix PCH reference clock for FDI on HSW/BDW")
>
> from the drm-intel-fixes tree and commit:
>
> 7d423af9bfb1 ("drm/i915: Implement a better i945gm vblank irq vs. C-states workaround")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/i915_drv.h
> index 953e1d12c23c,8882c0908c3b..000000000000
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@@ -1704,34 -1339,17 +1339,19 @@@ struct drm_i915_private
> struct {
> struct notifier_block pm_notifier;
>
> - /**
> - * We leave the user IRQ off as much as possible,
> - * but this means that requests will finish and never
> - * be retired once the system goes idle. Set a timer to
> - * fire periodically while the ring is running. When it
> - * fires, go retire requests.
> - */
> - struct delayed_work retire_work;
> -
> - /**
> - * When we detect an idle GPU, we want to turn on
> - * powersaving features. So once we see that there
> - * are no more requests outstanding and no more
> - * arrive within a small period of time, we fire
> - * off the idle_work.
> - */
> - struct work_struct idle_work;
> + struct i915_gem_contexts {
> + spinlock_t lock; /* locks list */
> + struct list_head list;
> +
> + struct llist_head free_list;
> + struct work_struct free_work;
> + } contexts;
> } gem;
>
> + u8 pch_ssc_use;
> +
> - /* For i945gm vblank irq vs. C3 workaround */
> - struct {
> - struct work_struct work;
> - struct pm_qos_request pm_qos;
> - u8 c3_disable_latency;
> - u8 enabled;
> - } i945gm_vblank;
> + /* For i915gm/i945gm vblank irq workaround */
> + u8 vblank_enabled;
>
> /* perform PHY state sanity checks? */
> bool chv_phy_assert[2];
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Dave Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Intel Graphics <intel-gfx@lists.freedesktop.org>,
DRI <dri-devel@lists.freedesktop.org>
Cc: Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Date: Fri, 8 Nov 2019 11:42:44 +1100 [thread overview]
Message-ID: <20191108114244.357c594f@canb.auug.org.au> (raw)
In-Reply-To: <20191031113315.4183cc7a@canb.auug.org.au>
[-- Attachment #1.1: Type: text/plain, Size: 2595 bytes --]
Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Thu, 31 Oct 2019 11:33:15 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.h
>
> between commit:
>
> 59cd826fb5e7 ("drm/i915: Fix PCH reference clock for FDI on HSW/BDW")
>
> from the drm-intel-fixes tree and commit:
>
> 7d423af9bfb1 ("drm/i915: Implement a better i945gm vblank irq vs. C-states workaround")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/i915_drv.h
> index 953e1d12c23c,8882c0908c3b..000000000000
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@@ -1704,34 -1339,17 +1339,19 @@@ struct drm_i915_private
> struct {
> struct notifier_block pm_notifier;
>
> - /**
> - * We leave the user IRQ off as much as possible,
> - * but this means that requests will finish and never
> - * be retired once the system goes idle. Set a timer to
> - * fire periodically while the ring is running. When it
> - * fires, go retire requests.
> - */
> - struct delayed_work retire_work;
> -
> - /**
> - * When we detect an idle GPU, we want to turn on
> - * powersaving features. So once we see that there
> - * are no more requests outstanding and no more
> - * arrive within a small period of time, we fire
> - * off the idle_work.
> - */
> - struct work_struct idle_work;
> + struct i915_gem_contexts {
> + spinlock_t lock; /* locks list */
> + struct list_head list;
> +
> + struct llist_head free_list;
> + struct work_struct free_work;
> + } contexts;
> } gem;
>
> + u8 pch_ssc_use;
> +
> - /* For i945gm vblank irq vs. C3 workaround */
> - struct {
> - struct work_struct work;
> - struct pm_qos_request pm_qos;
> - u8 c3_disable_latency;
> - u8 enabled;
> - } i945gm_vblank;
> + /* For i915gm/i945gm vblank irq workaround */
> + u8 vblank_enabled;
>
> /* perform PHY state sanity checks? */
> bool chv_phy_assert[2];
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Dave Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Intel Graphics <intel-gfx@lists.freedesktop.org>,
DRI <dri-devel@lists.freedesktop.org>
Cc: Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Date: Fri, 8 Nov 2019 11:42:44 +1100 [thread overview]
Message-ID: <20191108114244.357c594f@canb.auug.org.au> (raw)
Message-ID: <20191108004244.gWqThbPV3oIi1SczoLBCTOFIaRbhshkmNUg5o2H1gIg@z> (raw)
In-Reply-To: <20191031113315.4183cc7a@canb.auug.org.au>
[-- Attachment #1.1: Type: text/plain, Size: 2595 bytes --]
Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Thu, 31 Oct 2019 11:33:15 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.h
>
> between commit:
>
> 59cd826fb5e7 ("drm/i915: Fix PCH reference clock for FDI on HSW/BDW")
>
> from the drm-intel-fixes tree and commit:
>
> 7d423af9bfb1 ("drm/i915: Implement a better i945gm vblank irq vs. C-states workaround")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/i915_drv.h
> index 953e1d12c23c,8882c0908c3b..000000000000
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@@ -1704,34 -1339,17 +1339,19 @@@ struct drm_i915_private
> struct {
> struct notifier_block pm_notifier;
>
> - /**
> - * We leave the user IRQ off as much as possible,
> - * but this means that requests will finish and never
> - * be retired once the system goes idle. Set a timer to
> - * fire periodically while the ring is running. When it
> - * fires, go retire requests.
> - */
> - struct delayed_work retire_work;
> -
> - /**
> - * When we detect an idle GPU, we want to turn on
> - * powersaving features. So once we see that there
> - * are no more requests outstanding and no more
> - * arrive within a small period of time, we fire
> - * off the idle_work.
> - */
> - struct work_struct idle_work;
> + struct i915_gem_contexts {
> + spinlock_t lock; /* locks list */
> + struct list_head list;
> +
> + struct llist_head free_list;
> + struct work_struct free_work;
> + } contexts;
> } gem;
>
> + u8 pch_ssc_use;
> +
> - /* For i945gm vblank irq vs. C3 workaround */
> - struct {
> - struct work_struct work;
> - struct pm_qos_request pm_qos;
> - u8 c3_disable_latency;
> - u8 enabled;
> - } i945gm_vblank;
> + /* For i915gm/i945gm vblank irq workaround */
> + u8 vblank_enabled;
>
> /* perform PHY state sanity checks? */
> bool chv_phy_assert[2];
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Dave Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Intel Graphics <intel-gfx@lists.freedesktop.org>,
DRI <dri-devel@lists.freedesktop.org>
Cc: Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Date: Fri, 8 Nov 2019 11:42:44 +1100 [thread overview]
Message-ID: <20191108114244.357c594f@canb.auug.org.au> (raw)
Message-ID: <20191108004244.lkO9rSCthFDeRjQbxjSsqP9dIDWWcCLqMglMzdFdBDw@z> (raw)
In-Reply-To: <20191031113315.4183cc7a@canb.auug.org.au>
[-- Attachment #1.1: Type: text/plain, Size: 2595 bytes --]
Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Thu, 31 Oct 2019 11:33:15 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.h
>
> between commit:
>
> 59cd826fb5e7 ("drm/i915: Fix PCH reference clock for FDI on HSW/BDW")
>
> from the drm-intel-fixes tree and commit:
>
> 7d423af9bfb1 ("drm/i915: Implement a better i945gm vblank irq vs. C-states workaround")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/i915_drv.h
> index 953e1d12c23c,8882c0908c3b..000000000000
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@@ -1704,34 -1339,17 +1339,19 @@@ struct drm_i915_private
> struct {
> struct notifier_block pm_notifier;
>
> - /**
> - * We leave the user IRQ off as much as possible,
> - * but this means that requests will finish and never
> - * be retired once the system goes idle. Set a timer to
> - * fire periodically while the ring is running. When it
> - * fires, go retire requests.
> - */
> - struct delayed_work retire_work;
> -
> - /**
> - * When we detect an idle GPU, we want to turn on
> - * powersaving features. So once we see that there
> - * are no more requests outstanding and no more
> - * arrive within a small period of time, we fire
> - * off the idle_work.
> - */
> - struct work_struct idle_work;
> + struct i915_gem_contexts {
> + spinlock_t lock; /* locks list */
> + struct list_head list;
> +
> + struct llist_head free_list;
> + struct work_struct free_work;
> + } contexts;
> } gem;
>
> + u8 pch_ssc_use;
> +
> - /* For i945gm vblank irq vs. C3 workaround */
> - struct {
> - struct work_struct work;
> - struct pm_qos_request pm_qos;
> - u8 c3_disable_latency;
> - u8 enabled;
> - } i945gm_vblank;
> + /* For i915gm/i945gm vblank irq workaround */
> + u8 vblank_enabled;
>
> /* perform PHY state sanity checks? */
> bool chv_phy_assert[2];
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-11-08 0:42 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-31 0:33 linux-next: manual merge of the drm tree with the drm-intel-fixes tree Stephen Rothwell
2019-10-31 0:33 ` [Intel-gfx] " Stephen Rothwell
2019-10-31 0:33 ` Stephen Rothwell
2019-11-08 0:42 ` Stephen Rothwell [this message]
2019-11-08 0:42 ` [Intel-gfx] " Stephen Rothwell
2019-11-08 0:42 ` Stephen Rothwell
2019-11-08 0:42 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2024-03-07 2:10 Stephen Rothwell
2024-03-07 8:27 ` Joonas Lahtinen
2023-04-17 14:39 broonie
2023-04-17 14:39 ` broonie
2022-05-17 1:26 Stephen Rothwell
2022-05-17 1:26 ` Stephen Rothwell
2022-02-25 16:14 broonie
2022-02-25 16:14 ` broonie
2022-02-22 17:03 broonie
2022-02-22 17:03 ` broonie
2020-05-08 3:50 Stephen Rothwell
2020-05-08 3:50 ` Stephen Rothwell
2020-05-07 2:43 Stephen Rothwell
2020-05-07 2:43 ` Stephen Rothwell
2020-01-22 0:37 Stephen Rothwell
2020-01-22 0:37 ` Stephen Rothwell
2020-01-08 1:15 Stephen Rothwell
2020-01-08 1:15 ` Stephen Rothwell
2020-01-08 1:10 Stephen Rothwell
2020-01-08 1:10 ` Stephen Rothwell
2020-01-08 1:04 Stephen Rothwell
2020-01-08 1:04 ` Stephen Rothwell
2020-01-08 2:28 ` Stephen Rothwell
2020-01-08 2:28 ` Stephen Rothwell
2018-01-05 1:00 Stephen Rothwell
2018-01-05 1:00 ` Stephen Rothwell
2017-07-21 1:26 Stephen Rothwell
2017-07-21 1:26 ` Stephen Rothwell
2017-06-14 0:56 Stephen Rothwell
2017-06-14 0:56 ` Stephen Rothwell
2017-06-14 0:50 Stephen Rothwell
2017-06-09 2:26 Stephen Rothwell
2017-06-08 2:53 Stephen Rothwell
2017-06-08 2:53 ` Stephen Rothwell
2017-03-30 1:14 Stephen Rothwell
2017-03-30 1:08 Stephen Rothwell
2017-03-30 1:08 ` Stephen Rothwell
2017-03-22 0:00 Stephen Rothwell
2017-03-22 0:00 ` Stephen Rothwell
2017-03-27 17:14 ` Paul McKenney
2017-03-21 23:57 Stephen Rothwell
2017-03-21 23:57 ` Stephen Rothwell
2017-03-21 0:28 Stephen Rothwell
2017-03-21 0:28 ` Stephen Rothwell
2016-06-14 2:10 Stephen Rothwell
2016-06-14 2:10 ` Stephen Rothwell
2015-12-22 23:06 Stephen Rothwell
2015-12-22 23:06 ` Stephen Rothwell
2015-12-09 2:35 Stephen Rothwell
2015-12-09 2:35 ` Stephen Rothwell
2015-12-03 14:51 Mark Brown
2015-12-03 15:49 ` Jani Nikula
2015-12-03 15:49 ` Jani Nikula
2015-12-03 14:47 Mark Brown
2015-12-03 14:52 ` Imre Deak
2015-08-17 3:23 Stephen Rothwell
2015-08-17 3:23 ` Stephen Rothwell
2015-06-05 5:46 mpe@ellerman.id.au
2015-06-05 8:03 ` Jani Nikula
2015-06-05 8:03 ` Jani Nikula
2015-06-09 1:58 ` Stephen Rothwell
2015-06-09 1:58 ` Stephen Rothwell
2015-03-16 2:30 Stephen Rothwell
2015-03-16 2:30 ` Stephen Rothwell
2015-03-16 13:43 ` Xi Ruoyao
2015-03-16 15:04 ` Jani Nikula
2014-12-03 2:27 Stephen Rothwell
2014-12-03 2:27 ` Stephen Rothwell
2014-12-03 8:24 ` Jani Nikula
2014-12-03 8:24 ` Jani Nikula
2014-12-03 8:28 ` Stephen Rothwell
2014-11-17 3:04 Stephen Rothwell
2014-11-17 3:04 ` Stephen Rothwell
2014-07-23 2:38 Stephen Rothwell
2014-07-23 2:38 ` Stephen Rothwell
2014-07-09 4:06 Stephen Rothwell
2014-05-22 5:44 Stephen Rothwell
2014-05-22 5:40 Stephen Rothwell
2014-05-07 3:24 Stephen Rothwell
2013-10-28 5:46 Stephen Rothwell
2013-10-28 5:46 ` Stephen Rothwell
2013-10-28 6:12 ` Stephen Rothwell
2013-10-28 6:12 ` Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191108114244.357c594f@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=airlied@linux.ie \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.