All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: 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>,
	Dave Airlie <airlied@redhat.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>,
	Jani Nikula <jani.nikula@intel.com>,
	Intel Graphics <intel-gfx@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DRI <dri-devel@lists.freedesktop.org>,
	Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: linux-next: manual merge of the drm-intel tree with the drm tree
Date: Wed, 25 Jan 2023 10:42:48 +1100	[thread overview]
Message-ID: <20230125104248.1e9775ca@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  f67986b0119c ("drm/i915/pxp: Promote pxp subsystem to top-level of i915")

from the drm tree and commit:

  a3f839762ceb ("drm/i915: move pch_ssc_use to display sub-struct under dpll")

from the drm-intel 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 48fd82722f12,ac4c3c6f5541..000000000000
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -65,26 -65,40 +65,41 @@@
  #include "intel_uncore.h"
  
  struct drm_i915_clock_gating_funcs;
- struct drm_i915_gem_object;
- struct drm_i915_private;
- struct intel_connector;
- struct intel_dp;
- struct intel_encoder;
- struct intel_limit;
- struct intel_overlay_error_state;
  struct vlv_s0ix_state;
 +struct intel_pxp;
  
- #define I915_GEM_GPU_DOMAINS \
- 	(I915_GEM_DOMAIN_RENDER | \
- 	 I915_GEM_DOMAIN_SAMPLER | \
- 	 I915_GEM_DOMAIN_COMMAND | \
- 	 I915_GEM_DOMAIN_INSTRUCTION | \
- 	 I915_GEM_DOMAIN_VERTEX)
+ #define GEM_QUIRK_PIN_SWIZZLED_PAGES	BIT(0)
  
- #define I915_COLOR_UNEVICTABLE (-1) /* a non-vma sharing the address space */
+ /* Data Stolen Memory (DSM) aka "i915 stolen memory" */
+ struct i915_dsm {
+ 	/*
+ 	 * The start and end of DSM which we can optionally use to create GEM
+ 	 * objects backed by stolen memory.
+ 	 *
+ 	 * Note that usable_size tells us exactly how much of this we are
+ 	 * actually allowed to use, given that some portion of it is in fact
+ 	 * reserved for use by hardware functions.
+ 	 */
+ 	struct resource stolen;
  
- #define GEM_QUIRK_PIN_SWIZZLED_PAGES	BIT(0)
+ 	/*
+ 	 * Reserved portion of DSM.
+ 	 */
+ 	struct resource reserved;
+ 
+ 	/*
+ 	 * Total size minus reserved ranges.
+ 	 *
+ 	 * DSM is segmented in hardware with different portions offlimits to
+ 	 * certain functions.
+ 	 *
+ 	 * The drm_mm is initialised to the total accessible range, as found
+ 	 * from the PCI config. On Broadwell+, this is further restricted to
+ 	 * avoid the first page! The upper end of DSM is reserved for hardware
+ 	 * functions and similarly removed from the accessible range.
+ 	 */
+ 	resource_size_t usable_size;
+ };
  
  struct i915_suspend_saved_registers {
  	u32 saveDSPARB;
@@@ -366,10 -337,6 +338,8 @@@ struct drm_i915_private 
  		struct file *mmap_singleton;
  	} gem;
  
 +	struct intel_pxp *pxp;
 +
- 	u8 pch_ssc_use;
- 
  	/* For i915gm/i945gm vblank irq workaround */
  	u8 vblank_enabled;
  

[-- 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: 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>,
	Dave Airlie <airlied@redhat.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>,
	Jani Nikula <jani.nikula@intel.com>,
	Intel Graphics <intel-gfx@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DRI <dri-devel@lists.freedesktop.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm tree
Date: Wed, 25 Jan 2023 10:42:48 +1100	[thread overview]
Message-ID: <20230125104248.1e9775ca@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  f67986b0119c ("drm/i915/pxp: Promote pxp subsystem to top-level of i915")

from the drm tree and commit:

  a3f839762ceb ("drm/i915: move pch_ssc_use to display sub-struct under dpll")

from the drm-intel 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 48fd82722f12,ac4c3c6f5541..000000000000
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -65,26 -65,40 +65,41 @@@
  #include "intel_uncore.h"
  
  struct drm_i915_clock_gating_funcs;
- struct drm_i915_gem_object;
- struct drm_i915_private;
- struct intel_connector;
- struct intel_dp;
- struct intel_encoder;
- struct intel_limit;
- struct intel_overlay_error_state;
  struct vlv_s0ix_state;
 +struct intel_pxp;
  
- #define I915_GEM_GPU_DOMAINS \
- 	(I915_GEM_DOMAIN_RENDER | \
- 	 I915_GEM_DOMAIN_SAMPLER | \
- 	 I915_GEM_DOMAIN_COMMAND | \
- 	 I915_GEM_DOMAIN_INSTRUCTION | \
- 	 I915_GEM_DOMAIN_VERTEX)
+ #define GEM_QUIRK_PIN_SWIZZLED_PAGES	BIT(0)
  
- #define I915_COLOR_UNEVICTABLE (-1) /* a non-vma sharing the address space */
+ /* Data Stolen Memory (DSM) aka "i915 stolen memory" */
+ struct i915_dsm {
+ 	/*
+ 	 * The start and end of DSM which we can optionally use to create GEM
+ 	 * objects backed by stolen memory.
+ 	 *
+ 	 * Note that usable_size tells us exactly how much of this we are
+ 	 * actually allowed to use, given that some portion of it is in fact
+ 	 * reserved for use by hardware functions.
+ 	 */
+ 	struct resource stolen;
  
- #define GEM_QUIRK_PIN_SWIZZLED_PAGES	BIT(0)
+ 	/*
+ 	 * Reserved portion of DSM.
+ 	 */
+ 	struct resource reserved;
+ 
+ 	/*
+ 	 * Total size minus reserved ranges.
+ 	 *
+ 	 * DSM is segmented in hardware with different portions offlimits to
+ 	 * certain functions.
+ 	 *
+ 	 * The drm_mm is initialised to the total accessible range, as found
+ 	 * from the PCI config. On Broadwell+, this is further restricted to
+ 	 * avoid the first page! The upper end of DSM is reserved for hardware
+ 	 * functions and similarly removed from the accessible range.
+ 	 */
+ 	resource_size_t usable_size;
+ };
  
  struct i915_suspend_saved_registers {
  	u32 saveDSPARB;
@@@ -366,10 -337,6 +338,8 @@@ struct drm_i915_private 
  		struct file *mmap_singleton;
  	} gem;
  
 +	struct intel_pxp *pxp;
 +
- 	u8 pch_ssc_use;
- 
  	/* For i915gm/i945gm vblank irq workaround */
  	u8 vblank_enabled;
  

[-- 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: 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>,
	Dave Airlie <airlied@redhat.com>
Cc: Intel Graphics <intel-gfx@lists.freedesktop.org>,
	DRI <dri-devel@lists.freedesktop.org>,
	Alan Previn <alan.previn.teres.alexis@intel.com>,
	Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	Jani Nikula <jani.nikula@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: linux-next: manual merge of the drm-intel tree with the drm tree
Date: Wed, 25 Jan 2023 10:42:48 +1100	[thread overview]
Message-ID: <20230125104248.1e9775ca@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  f67986b0119c ("drm/i915/pxp: Promote pxp subsystem to top-level of i915")

from the drm tree and commit:

  a3f839762ceb ("drm/i915: move pch_ssc_use to display sub-struct under dpll")

from the drm-intel 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 48fd82722f12,ac4c3c6f5541..000000000000
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -65,26 -65,40 +65,41 @@@
  #include "intel_uncore.h"
  
  struct drm_i915_clock_gating_funcs;
- struct drm_i915_gem_object;
- struct drm_i915_private;
- struct intel_connector;
- struct intel_dp;
- struct intel_encoder;
- struct intel_limit;
- struct intel_overlay_error_state;
  struct vlv_s0ix_state;
 +struct intel_pxp;
  
- #define I915_GEM_GPU_DOMAINS \
- 	(I915_GEM_DOMAIN_RENDER | \
- 	 I915_GEM_DOMAIN_SAMPLER | \
- 	 I915_GEM_DOMAIN_COMMAND | \
- 	 I915_GEM_DOMAIN_INSTRUCTION | \
- 	 I915_GEM_DOMAIN_VERTEX)
+ #define GEM_QUIRK_PIN_SWIZZLED_PAGES	BIT(0)
  
- #define I915_COLOR_UNEVICTABLE (-1) /* a non-vma sharing the address space */
+ /* Data Stolen Memory (DSM) aka "i915 stolen memory" */
+ struct i915_dsm {
+ 	/*
+ 	 * The start and end of DSM which we can optionally use to create GEM
+ 	 * objects backed by stolen memory.
+ 	 *
+ 	 * Note that usable_size tells us exactly how much of this we are
+ 	 * actually allowed to use, given that some portion of it is in fact
+ 	 * reserved for use by hardware functions.
+ 	 */
+ 	struct resource stolen;
  
- #define GEM_QUIRK_PIN_SWIZZLED_PAGES	BIT(0)
+ 	/*
+ 	 * Reserved portion of DSM.
+ 	 */
+ 	struct resource reserved;
+ 
+ 	/*
+ 	 * Total size minus reserved ranges.
+ 	 *
+ 	 * DSM is segmented in hardware with different portions offlimits to
+ 	 * certain functions.
+ 	 *
+ 	 * The drm_mm is initialised to the total accessible range, as found
+ 	 * from the PCI config. On Broadwell+, this is further restricted to
+ 	 * avoid the first page! The upper end of DSM is reserved for hardware
+ 	 * functions and similarly removed from the accessible range.
+ 	 */
+ 	resource_size_t usable_size;
+ };
  
  struct i915_suspend_saved_registers {
  	u32 saveDSPARB;
@@@ -366,10 -337,6 +338,8 @@@ struct drm_i915_private 
  		struct file *mmap_singleton;
  	} gem;
  
 +	struct intel_pxp *pxp;
 +
- 	u8 pch_ssc_use;
- 
  	/* For i915gm/i945gm vblank irq workaround */
  	u8 vblank_enabled;
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2023-01-24 23:42 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 23:42 Stephen Rothwell [this message]
2023-01-24 23:42 ` linux-next: manual merge of the drm-intel tree with the drm tree Stephen Rothwell
2023-01-24 23:42 ` [Intel-gfx] " Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2023-10-03  0:09 Stephen Rothwell
2023-10-03  0:09 ` Stephen Rothwell
2023-10-05 14:41 ` Jani Nikula
2023-05-30  1:59 Stephen Rothwell
2023-05-30  1:59 ` Stephen Rothwell
2023-05-30  1:57 Stephen Rothwell
2023-05-30  1:57 ` Stephen Rothwell
2023-05-30  2:10 ` Stephen Rothwell
2023-05-30  2:10   ` Stephen Rothwell
2022-09-13  2:19 Stephen Rothwell
2022-09-13  2:19 ` Stephen Rothwell
2022-09-12  1:46 Stephen Rothwell
2022-09-12  1:46 ` Stephen Rothwell
2022-02-11  2:06 Stephen Rothwell
2022-02-11  2:06 ` Stephen Rothwell
2022-02-09  0:55 Stephen Rothwell
2022-02-09  0:55 ` Stephen Rothwell
2021-08-12  1:28 Stephen Rothwell
2021-04-01  2:13 Stephen Rothwell
2021-04-01  2:13 ` Stephen Rothwell
2021-03-17  3:08 Stephen Rothwell
2021-03-17  3:08 ` Stephen Rothwell
2021-03-18  1:52 ` Stephen Rothwell
2021-03-18  1:52   ` Stephen Rothwell
2021-04-29 22:23   ` Stephen Rothwell
2021-04-29 22:23     ` Stephen Rothwell
2021-05-14  1:53     ` Stephen Rothwell
2021-05-14  1:53       ` Stephen Rothwell
2021-05-14 12:14       ` Thomas Zimmermann
2021-01-25  0:46 Stephen Rothwell
2021-01-25  0:46 ` Stephen Rothwell
2020-07-14  2:59 Stephen Rothwell
2020-07-14  2:59 ` Stephen Rothwell
2019-08-22  3:15 Stephen Rothwell
2019-02-06  0:42 Stephen Rothwell
2019-01-17  1:59 Stephen Rothwell
2019-01-17  1:59 ` Stephen Rothwell
2017-05-19  2:04 Stephen Rothwell
2016-09-07  3:59 Stephen Rothwell
2014-07-23  3:18 Stephen Rothwell
2014-07-23  3:18 ` Stephen Rothwell
2014-07-23  3:06 Stephen Rothwell
2014-07-23  3:06 ` Stephen Rothwell
2014-07-23  5:09 ` Daniel Vetter
2014-07-23  5:09   ` Daniel Vetter
2014-04-03  1:00 Stephen Rothwell
2014-04-03  1:00 ` Stephen Rothwell
2014-01-22  3:09 Stephen Rothwell
2014-01-22  3:09 ` Stephen Rothwell
2014-01-22  3:04 Stephen Rothwell
2014-01-22  3:04 ` Stephen Rothwell
2014-01-22 10:06 ` Daniel Vetter
2014-01-23  1:21   ` Olof Johansson
2014-01-23  1:21     ` Olof Johansson
2014-01-23 21:10     ` Olof Johansson
2014-01-23 21:10       ` Olof Johansson
2013-11-07  2:37 Stephen Rothwell
2013-11-07  2:37 ` Stephen Rothwell
2013-08-29  4:09 Stephen Rothwell
2013-08-29  4:09 ` Stephen Rothwell
2013-06-18  3:04 Stephen Rothwell
2013-06-18  3:04 ` Stephen Rothwell
2013-05-01  4:37 Stephen Rothwell
2013-05-01  8:08 ` Daniel Vetter

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=20230125104248.1e9775ca@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=airlied@redhat.com \
    --cc=alan.previn.teres.alexis@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --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 \
    /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.