* [PATCH 0/3] Deprecate legacy crap
@ 2013-11-11 8:35 Daniel Vetter
2013-11-11 8:35 ` [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 Daniel Vetter
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Daniel Vetter @ 2013-11-11 8:35 UTC (permalink / raw)
To: Intel Graphics Development; +Cc: Daniel Vetter, DRI Development
Hi all,
Spurred by Ian's abuse of drmAgpSize I've figued it's time we accelerate the
demisse of the fake agp stuff and our ums code a bit. The idea is to send out
the same probe the radone guys have done and deprecate legacy stuff for now.
Then (presuming we don't get any reports from hurt users) we can rip the code
out after a few releases.
In both cases (killing fake agp and killing ums) we can just keep doing what
we've done thus far as contingency. But for ums I expect that we need to
copy-paste the driver long term to stay sane. Just removing it is obviously
easier ;-)
Cheers, Daniel
Daniel Vetter (3):
drm/i915: Make AGP=n work even on gen3
drm/i915: Kill legeacy AGP for gen3 kms
drm/i915: Deprecated UMS support
drivers/gpu/drm/i915/Kconfig | 24 +++++++++++++++++++-----
drivers/gpu/drm/i915/i915_drv.c | 14 ++------------
2 files changed, 21 insertions(+), 17 deletions(-)
--
1.8.4.rc3
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 2013-11-11 8:35 [PATCH 0/3] Deprecate legacy crap Daniel Vetter @ 2013-11-11 8:35 ` Daniel Vetter 2013-11-13 18:59 ` Ville Syrjälä 2013-11-11 8:35 ` [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms Daniel Vetter 2013-11-11 8:35 ` [PATCH 3/3] drm/i915: Deprecated UMS support Daniel Vetter 2 siblings, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2013-11-11 8:35 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter, DRI Development Most platforms din't hit this condition, but if we want to allow building without agp we should also make this allowed on gen3. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 38a344694e35..d7c922051c89 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -158,7 +158,7 @@ static struct drm_driver driver; #if IS_ENABLED(CONFIG_AGP_INTEL) extern int intel_agp_enabled; #else -static int intel_agp_enabled; +static int intel_agp_enabled = 1; #endif static const struct intel_device_info intel_i830_info = { -- 1.8.4.rc3 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 2013-11-11 8:35 ` [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 Daniel Vetter @ 2013-11-13 18:59 ` Ville Syrjälä 2013-11-13 20:21 ` Daniel Vetter 0 siblings, 1 reply; 14+ messages in thread From: Ville Syrjälä @ 2013-11-13 18:59 UTC (permalink / raw) To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development On Mon, Nov 11, 2013 at 09:35:17AM +0100, Daniel Vetter wrote: > Most platforms din't hit this condition, but if we want to allow > building without agp we should also make this allowed on gen3. > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/gpu/drm/i915/i915_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 38a344694e35..d7c922051c89 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -158,7 +158,7 @@ static struct drm_driver driver; > #if IS_ENABLED(CONFIG_AGP_INTEL) > extern int intel_agp_enabled; > #else > -static int intel_agp_enabled; > +static int intel_agp_enabled = 1; Patch 2/3 eliminates our only use of intel_agp_enabled, so this patch seems pointless. > #endif > > static const struct intel_device_info intel_i830_info = { > -- > 1.8.4.rc3 -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 2013-11-13 18:59 ` Ville Syrjälä @ 2013-11-13 20:21 ` Daniel Vetter 2013-11-13 23:24 ` Ville Syrjälä 0 siblings, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2013-11-13 20:21 UTC (permalink / raw) To: Ville Syrjälä Cc: Daniel Vetter, Intel Graphics Development, DRI Development On Wed, Nov 13, 2013 at 08:59:56PM +0200, Ville Syrjälä wrote: > On Mon, Nov 11, 2013 at 09:35:17AM +0100, Daniel Vetter wrote: > > Most platforms din't hit this condition, but if we want to allow > > building without agp we should also make this allowed on gen3. > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > --- > > drivers/gpu/drm/i915/i915_drv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > > index 38a344694e35..d7c922051c89 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -158,7 +158,7 @@ static struct drm_driver driver; > > #if IS_ENABLED(CONFIG_AGP_INTEL) > > extern int intel_agp_enabled; > > #else > > -static int intel_agp_enabled; > > +static int intel_agp_enabled = 1; > > Patch 2/3 eliminates our only use of intel_agp_enabled, so this patch > seems pointless. Patch 2 has a good chance to get reverted, so having this separate isn't completely pointless. Should have mentioned this in the cover letter ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 2013-11-13 20:21 ` Daniel Vetter @ 2013-11-13 23:24 ` Ville Syrjälä 2013-11-14 0:43 ` Daniel Vetter 0 siblings, 1 reply; 14+ messages in thread From: Ville Syrjälä @ 2013-11-13 23:24 UTC (permalink / raw) To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development On Wed, Nov 13, 2013 at 09:21:44PM +0100, Daniel Vetter wrote: > On Wed, Nov 13, 2013 at 08:59:56PM +0200, Ville Syrjälä wrote: > > On Mon, Nov 11, 2013 at 09:35:17AM +0100, Daniel Vetter wrote: > > > Most platforms din't hit this condition, but if we want to allow > > > building without agp we should also make this allowed on gen3. > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > > --- > > > drivers/gpu/drm/i915/i915_drv.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > > > index 38a344694e35..d7c922051c89 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > @@ -158,7 +158,7 @@ static struct drm_driver driver; > > > #if IS_ENABLED(CONFIG_AGP_INTEL) > > > extern int intel_agp_enabled; > > > #else > > > -static int intel_agp_enabled; > > > +static int intel_agp_enabled = 1; > > > > Patch 2/3 eliminates our only use of intel_agp_enabled, so this patch > > seems pointless. > > Patch 2 has a good chance to get reverted, so having this separate isn't > completely pointless. Should have mentioned this in the cover letter ;-) OK, makes sense. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 2013-11-13 23:24 ` Ville Syrjälä @ 2013-11-14 0:43 ` Daniel Vetter 0 siblings, 0 replies; 14+ messages in thread From: Daniel Vetter @ 2013-11-14 0:43 UTC (permalink / raw) To: Ville Syrjälä Cc: Daniel Vetter, Intel Graphics Development, DRI Development On Thu, Nov 14, 2013 at 01:24:57AM +0200, Ville Syrjälä wrote: > On Wed, Nov 13, 2013 at 09:21:44PM +0100, Daniel Vetter wrote: > > On Wed, Nov 13, 2013 at 08:59:56PM +0200, Ville Syrjälä wrote: > > > On Mon, Nov 11, 2013 at 09:35:17AM +0100, Daniel Vetter wrote: > > > > Most platforms din't hit this condition, but if we want to allow > > > > building without agp we should also make this allowed on gen3. > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > > > --- > > > > drivers/gpu/drm/i915/i915_drv.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > > > > index 38a344694e35..d7c922051c89 100644 > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > @@ -158,7 +158,7 @@ static struct drm_driver driver; > > > > #if IS_ENABLED(CONFIG_AGP_INTEL) > > > > extern int intel_agp_enabled; > > > > #else > > > > -static int intel_agp_enabled; > > > > +static int intel_agp_enabled = 1; > > > > > > Patch 2/3 eliminates our only use of intel_agp_enabled, so this patch > > > seems pointless. > > > > Patch 2 has a good chance to get reverted, so having this separate isn't > > completely pointless. Should have mentioned this in the cover letter ;-) > > OK, makes sense. > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Ok, I've pulled them all in (with Dave's irc-ack for 2&3), thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms 2013-11-11 8:35 [PATCH 0/3] Deprecate legacy crap Daniel Vetter 2013-11-11 8:35 ` [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 Daniel Vetter @ 2013-11-11 8:35 ` Daniel Vetter 2013-11-13 19:00 ` Ville Syrjälä 2013-11-13 21:14 ` [PATCH] " Daniel Vetter 2013-11-11 8:35 ` [PATCH 3/3] drm/i915: Deprecated UMS support Daniel Vetter 2 siblings, 2 replies; 14+ messages in thread From: Daniel Vetter @ 2013-11-11 8:35 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter, DRI Development Thus far we've tried to carefully work around the fact that old userspace relied on the AGP-backed legacy buffer mapping ioctls for a bit too long. But it's really horribly, and now some new users for it started to show up again: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45547.html This uses drmAgpSize to figure out the GTT size, which is both the wrong thing to inquire and also might force us to keep this crap around for another few years. So I want to stop this particular zombie from raising ever again. Now it's only been 4 years since XvMC was fixed for gen3, so a bit early by the usual rules. But since Linus explicitly said that an ABI breakage only counts if someone actually observes it I want to tempt fate an accelarate the demise of AGP. We probably need to wait 2-3 kernel releases with this shipping until we go on a killing spree code-wise. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/i915_drv.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index d7c922051c89..93a8e0316bd0 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -797,17 +797,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (PCI_FUNC(pdev->devfn)) return -ENODEV; - /* We've managed to ship a kms-enabled ddx that shipped with an XvMC - * implementation for gen3 (and only gen3) that used legacy drm maps - * (gasp!) to share buffers between X and the client. Hence we need to - * keep around the fake agp stuff for gen3, even when kms is enabled. */ - if (intel_info->gen != 3) { - driver.driver_features &= - ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); - } else if (!intel_agp_enabled) { - DRM_ERROR("drm/i915 can't work without intel_agp module!\n"); - return -ENODEV; - } + driver.driver_features &= ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); return drm_get_pci_dev(pdev, ent, &driver); } -- 1.8.4.rc3 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms 2013-11-11 8:35 ` [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms Daniel Vetter @ 2013-11-13 19:00 ` Ville Syrjälä 2013-11-13 21:14 ` [PATCH] " Daniel Vetter 1 sibling, 0 replies; 14+ messages in thread From: Ville Syrjälä @ 2013-11-13 19:00 UTC (permalink / raw) To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development On Mon, Nov 11, 2013 at 09:35:18AM +0100, Daniel Vetter wrote: > Thus far we've tried to carefully work around the fact that old > userspace relied on the AGP-backed legacy buffer mapping ioctls for a > bit too long. But it's really horribly, and now some new users for it > started to show up again: > > http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45547.html > > This uses drmAgpSize to figure out the GTT size, which is both the > wrong thing to inquire and also might force us to keep this crap > around for another few years. > > So I want to stop this particular zombie from raising ever again. Now > it's only been 4 years since XvMC was fixed for gen3, so a bit early > by the usual rules. But since Linus explicitly said that an ABI > breakage only counts if someone actually observes it I want to tempt > fate an accelarate the demise of AGP. > > We probably need to wait 2-3 kernel releases with this shipping until > we go on a killing spree code-wise. > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Dave Airlie <airlied@gmail.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/gpu/drm/i915/i915_drv.c | 12 +----------- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index d7c922051c89..93a8e0316bd0 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -797,17 +797,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > if (PCI_FUNC(pdev->devfn)) > return -ENODEV; > > - /* We've managed to ship a kms-enabled ddx that shipped with an XvMC > - * implementation for gen3 (and only gen3) that used legacy drm maps > - * (gasp!) to share buffers between X and the client. Hence we need to > - * keep around the fake agp stuff for gen3, even when kms is enabled. */ > - if (intel_info->gen != 3) { > - driver.driver_features &= > - ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); > - } else if (!intel_agp_enabled) { > - DRM_ERROR("drm/i915 can't work without intel_agp module!\n"); > - return -ENODEV; > - } > + driver.driver_features &= ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); Nothing else uses intel_agp_enabled, so it could be killed entirely. > > return drm_get_pci_dev(pdev, ent, &driver); > } > -- > 1.8.4.rc3 -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] drm/i915: Kill legeacy AGP for gen3 kms 2013-11-11 8:35 ` [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms Daniel Vetter 2013-11-13 19:00 ` Ville Syrjälä @ 2013-11-13 21:14 ` Daniel Vetter 2013-11-13 23:20 ` Ville Syrjälä 1 sibling, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2013-11-13 21:14 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter Thus far we've tried to carefully work around the fact that old userspace relied on the AGP-backed legacy buffer mapping ioctls for a bit too long. But it's really horribly, and now some new users for it started to show up again: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45547.html This uses drmAgpSize to figure out the GTT size, which is both the wrong thing to inquire and also might force us to keep this crap around for another few years. So I want to stop this particular zombie from raising ever again. Now it's only been 4 years since XvMC was fixed for gen3, so a bit early by the usual rules. But since Linus explicitly said that an ABI breakage only counts if someone actually observes it I want to tempt fate an accelarate the demise of AGP. We probably need to wait 2-3 kernel releases with this shipping until we go on a killing spree code-wise. v2: Remove intel_agp_enabled since it's unused (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/char/agp/intel-agp.c | 5 ----- drivers/gpu/drm/i915/i915_drv.c | 17 +---------------- 2 files changed, 1 insertion(+), 21 deletions(-) diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c index a426ee1f57a6..9ef0a48a5b28 100644 --- a/drivers/char/agp/intel-agp.c +++ b/drivers/char/agp/intel-agp.c @@ -14,9 +14,6 @@ #include "intel-agp.h" #include <drm/intel-gtt.h> -int intel_agp_enabled; -EXPORT_SYMBOL(intel_agp_enabled); - static int intel_fetch_size(void) { int i; @@ -814,8 +811,6 @@ static int agp_intel_probe(struct pci_dev *pdev, found_gmch: pci_set_drvdata(pdev, bridge); err = agp_add_bridge(bridge); - if (!err) - intel_agp_enabled = 1; return err; } diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 8f93c1c1a622..9200c5c47d46 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -155,11 +155,6 @@ MODULE_PARM_DESC(prefault_disable, "Disable page prefaulting for pread/pwrite/reloc (default:false). For developers only."); static struct drm_driver driver; -#if IS_ENABLED(CONFIG_AGP_INTEL) -extern int intel_agp_enabled; -#else -static int intel_agp_enabled = 1; -#endif static const struct intel_device_info intel_i830_info = { .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2, @@ -829,17 +824,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (PCI_FUNC(pdev->devfn)) return -ENODEV; - /* We've managed to ship a kms-enabled ddx that shipped with an XvMC - * implementation for gen3 (and only gen3) that used legacy drm maps - * (gasp!) to share buffers between X and the client. Hence we need to - * keep around the fake agp stuff for gen3, even when kms is enabled. */ - if (intel_info->gen != 3) { - driver.driver_features &= - ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); - } else if (!intel_agp_enabled) { - DRM_ERROR("drm/i915 can't work without intel_agp module!\n"); - return -ENODEV; - } + driver.driver_features &= ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); return drm_get_pci_dev(pdev, ent, &driver); } -- 1.8.4.3 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] drm/i915: Kill legeacy AGP for gen3 kms 2013-11-13 21:14 ` [PATCH] " Daniel Vetter @ 2013-11-13 23:20 ` Ville Syrjälä 0 siblings, 0 replies; 14+ messages in thread From: Ville Syrjälä @ 2013-11-13 23:20 UTC (permalink / raw) To: Daniel Vetter; +Cc: Intel Graphics Development On Wed, Nov 13, 2013 at 10:14:16PM +0100, Daniel Vetter wrote: > Thus far we've tried to carefully work around the fact that old > userspace relied on the AGP-backed legacy buffer mapping ioctls for a > bit too long. But it's really horribly, and now some new users for it > started to show up again: > > http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45547.html > > This uses drmAgpSize to figure out the GTT size, which is both the > wrong thing to inquire and also might force us to keep this crap > around for another few years. > > So I want to stop this particular zombie from raising ever again. Now > it's only been 4 years since XvMC was fixed for gen3, so a bit early > by the usual rules. But since Linus explicitly said that an ABI > breakage only counts if someone actually observes it I want to tempt > fate an accelarate the demise of AGP. > > We probably need to wait 2-3 kernel releases with this shipping until > we go on a killing spree code-wise. > > v2: Remove intel_agp_enabled since it's unused (Ville). > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Dave Airlie <airlied@gmail.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/char/agp/intel-agp.c | 5 ----- > drivers/gpu/drm/i915/i915_drv.c | 17 +---------------- > 2 files changed, 1 insertion(+), 21 deletions(-) > > diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c > index a426ee1f57a6..9ef0a48a5b28 100644 > --- a/drivers/char/agp/intel-agp.c > +++ b/drivers/char/agp/intel-agp.c > @@ -14,9 +14,6 @@ > #include "intel-agp.h" > #include <drm/intel-gtt.h> > > -int intel_agp_enabled; > -EXPORT_SYMBOL(intel_agp_enabled); > - > static int intel_fetch_size(void) > { > int i; > @@ -814,8 +811,6 @@ static int agp_intel_probe(struct pci_dev *pdev, > found_gmch: > pci_set_drvdata(pdev, bridge); > err = agp_add_bridge(bridge); > - if (!err) > - intel_agp_enabled = 1; > return err; > } > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 8f93c1c1a622..9200c5c47d46 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -155,11 +155,6 @@ MODULE_PARM_DESC(prefault_disable, > "Disable page prefaulting for pread/pwrite/reloc (default:false). For developers only."); > > static struct drm_driver driver; > -#if IS_ENABLED(CONFIG_AGP_INTEL) > -extern int intel_agp_enabled; > -#else > -static int intel_agp_enabled = 1; > -#endif > > static const struct intel_device_info intel_i830_info = { > .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2, > @@ -829,17 +824,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > if (PCI_FUNC(pdev->devfn)) > return -ENODEV; > > - /* We've managed to ship a kms-enabled ddx that shipped with an XvMC > - * implementation for gen3 (and only gen3) that used legacy drm maps > - * (gasp!) to share buffers between X and the client. Hence we need to > - * keep around the fake agp stuff for gen3, even when kms is enabled. */ > - if (intel_info->gen != 3) { > - driver.driver_features &= > - ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); > - } else if (!intel_agp_enabled) { > - DRM_ERROR("drm/i915 can't work without intel_agp module!\n"); > - return -ENODEV; > - } > + driver.driver_features &= ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP); > > return drm_get_pci_dev(pdev, ent, &driver); > } > -- > 1.8.4.3 -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 3/3] drm/i915: Deprecated UMS support 2013-11-11 8:35 [PATCH 0/3] Deprecate legacy crap Daniel Vetter 2013-11-11 8:35 ` [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 Daniel Vetter 2013-11-11 8:35 ` [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms Daniel Vetter @ 2013-11-11 8:35 ` Daniel Vetter 2013-11-13 19:01 ` Ville Syrjälä 2013-11-13 21:11 ` [PATCH] " Daniel Vetter 2 siblings, 2 replies; 14+ messages in thread From: Daniel Vetter @ 2013-11-11 8:35 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter, DRI Development It's been 5 years since kms support was merged and roughly 4 years since UMS support was ripped out from userspace drivers. Thus far it's not been a big burden to keep the ums paths alive, and we've made some good progress in better separating it from the kms code by sprinkling DRIVER_MODESET checks all over the place. But now that the drm demidlayering is within reach this changes. I want to make the driver loading code more robust using devres.c and other cool tricks. But that doesn't work with ums due to the shadow-attach trick. Which means we either a) need to split out a complete ums codebase like radeon has b) kill it for good. The 2nd option is obviously much less work than the first, so I think it's time to test the waters and see how many people out there still use ums. I've decided that silently failing to initialize the driver (and not e.g. failing to load the module) is the right thing. That way we should only get reports from users that actually care about some ums features (like accelerated gl or support for secondary outputs). Everyone else will just fall back to the vesa X driver. For developers there's a small info level dmesg output. The plan is to drop this Kconfig option after 3.16 (so gives us 2 full releases) and then start killing code for real 2-3 releases afterwards. That should be more than enough time for users to pipe up. Of course if anyone does we need to revisit this plan and maybe go with option a) above. Also enable the KMS support by default in Kconfig and polish the help texts a bit. Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/Kconfig | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index b0f61679c598..b0fa4c4055ee 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -37,12 +37,11 @@ config DRM_I915 config DRM_I915_KMS bool "Enable modesetting on intel by default" depends on DRM_I915 + default y help - Choose this option if you want kernel modesetting enabled by default, - and you have a new enough userspace to support this. Running old - userspaces with this enabled will cause pain. Note that this causes - the driver to bind to PCI devices, which precludes loading things - like intelfb. + Choose this option if you want kernel modesetting enabled by default. + + If in doubt, say "Y". config DRM_I915_FBDEV bool "Enable legacy fbdev support for the modesettting intel driver" @@ -57,9 +56,12 @@ config DRM_I915_FBDEV support. Note that this support also provide the linux console support on top of the intel modesetting driver. + If in doubt, say "Y". + config DRM_I915_PRELIMINARY_HW_SUPPORT bool "Enable preliminary support for prerelease Intel hardware by default" depends on DRM_I915 + default n help Choose this option if you have prerelease Intel hardware and want the i915 driver to support it by default. You can enable such support at @@ -67,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT option changes the default for that module option. If in doubt, say "N". + +config DRM_I915_UMS + bool "Enable userspace modesetting on Intel hardware (DEPRECATED)" + depends on DRM_I915 + default n + help + Choose this option if you still need userspace modesetting. + + Userspace modesetting is deprecated for quite some time now, so + enable this only if you have ancient versions of the DDX drivers. + + If in doubt, say "N". -- 1.8.4.rc3 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 3/3] drm/i915: Deprecated UMS support 2013-11-11 8:35 ` [PATCH 3/3] drm/i915: Deprecated UMS support Daniel Vetter @ 2013-11-13 19:01 ` Ville Syrjälä 2013-11-13 21:11 ` [PATCH] " Daniel Vetter 1 sibling, 0 replies; 14+ messages in thread From: Ville Syrjälä @ 2013-11-13 19:01 UTC (permalink / raw) To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development On Mon, Nov 11, 2013 at 09:35:19AM +0100, Daniel Vetter wrote: > It's been 5 years since kms support was merged and roughly 4 years > since UMS support was ripped out from userspace drivers. > > Thus far it's not been a big burden to keep the ums paths alive, and > we've made some good progress in better separating it from the kms > code by sprinkling DRIVER_MODESET checks all over the place. > > But now that the drm demidlayering is within reach this changes. I > want to make the driver loading code more robust using devres.c and > other cool tricks. But that doesn't work with ums due to the > shadow-attach trick. Which means we either > a) need to split out a complete ums codebase like radeon has > b) kill it for good. > > The 2nd option is obviously much less work than the first, so I think > it's time to test the waters and see how many people out there still > use ums. > > I've decided that silently failing to initialize the driver (and not > e.g. failing to load the module) is the right thing. That way we > should only get reports from users that actually care about some ums > features (like accelerated gl or support for secondary outputs). > Everyone else will just fall back to the vesa X driver. > > For developers there's a small info level dmesg output. > > The plan is to drop this Kconfig option after 3.16 (so gives us 2 full > releases) and then start killing code for real 2-3 releases > afterwards. That should be more than enough time for users to pipe up. > > Of course if anyone does we need to revisit this plan and maybe go > with option a) above. > > Also enable the KMS support by default in Kconfig and polish the help > texts a bit. > > Cc: Dave Airlie <airlied@gmail.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/gpu/drm/i915/Kconfig | 24 +++++++++++++++++++----- > 1 file changed, 19 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index b0f61679c598..b0fa4c4055ee 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -37,12 +37,11 @@ config DRM_I915 > config DRM_I915_KMS > bool "Enable modesetting on intel by default" > depends on DRM_I915 > + default y > help > - Choose this option if you want kernel modesetting enabled by default, > - and you have a new enough userspace to support this. Running old > - userspaces with this enabled will cause pain. Note that this causes > - the driver to bind to PCI devices, which precludes loading things > - like intelfb. > + Choose this option if you want kernel modesetting enabled by default. > + > + If in doubt, say "Y". > > config DRM_I915_FBDEV > bool "Enable legacy fbdev support for the modesettting intel driver" > @@ -57,9 +56,12 @@ config DRM_I915_FBDEV > support. Note that this support also provide the linux console > support on top of the intel modesetting driver. > > + If in doubt, say "Y". > + > config DRM_I915_PRELIMINARY_HW_SUPPORT > bool "Enable preliminary support for prerelease Intel hardware by default" > depends on DRM_I915 > + default n > help > Choose this option if you have prerelease Intel hardware and want the > i915 driver to support it by default. You can enable such support at > @@ -67,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT > option changes the default for that module option. > > If in doubt, say "N". > + > +config DRM_I915_UMS Was there supposed to be some user for this config option? > + bool "Enable userspace modesetting on Intel hardware (DEPRECATED)" > + depends on DRM_I915 > + default n > + help > + Choose this option if you still need userspace modesetting. > + > + Userspace modesetting is deprecated for quite some time now, so > + enable this only if you have ancient versions of the DDX drivers. > + > + If in doubt, say "N". > -- > 1.8.4.rc3 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] drm/i915: Deprecated UMS support 2013-11-11 8:35 ` [PATCH 3/3] drm/i915: Deprecated UMS support Daniel Vetter 2013-11-13 19:01 ` Ville Syrjälä @ 2013-11-13 21:11 ` Daniel Vetter 2013-11-13 23:18 ` Ville Syrjälä 1 sibling, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2013-11-13 21:11 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter It's been 5 years since kms support was merged and roughly 4 years since UMS support was ripped out from userspace drivers. Thus far it's not been a big burden to keep the ums paths alive, and we've made some good progress in better separating it from the kms code by sprinkling DRIVER_MODESET checks all over the place. But now that the drm demidlayering is within reach this changes. I want to make the driver loading code more robust using devres.c and other cool tricks. But that doesn't work with ums due to the shadow-attach trick. Which means we either a) need to split out a complete ums codebase like radeon has b) kill it for good. The 2nd option is obviously much less work than the first, so I think it's time to test the waters and see how many people out there still use ums. I've decided that silently failing to initialize the driver (and not e.g. failing to load the module) is the right thing. That way we should only get reports from users that actually care about some ums features (like accelerated gl or support for secondary outputs). Everyone else will just fall back to the vesa X driver. For developers there's a small info level dmesg output. The plan is to drop this Kconfig option after 3.16 (so gives us 2 full releases) and then start killing code for real 2-3 releases afterwards. That should be more than enough time for users to pipe up. Of course if anyone does we need to revisit this plan and maybe go with option a) above. Also enable the KMS support by default in Kconfig and polish the help texts a bit. v2: Add the missing hunk of actual code changes. Oops. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/Kconfig | 24 +++++++++++++++++++----- drivers/gpu/drm/i915/i915_drv.c | 7 ++++++- 2 files changed, 25 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index b0f61679c598..b0fa4c4055ee 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -37,12 +37,11 @@ config DRM_I915 config DRM_I915_KMS bool "Enable modesetting on intel by default" depends on DRM_I915 + default y help - Choose this option if you want kernel modesetting enabled by default, - and you have a new enough userspace to support this. Running old - userspaces with this enabled will cause pain. Note that this causes - the driver to bind to PCI devices, which precludes loading things - like intelfb. + Choose this option if you want kernel modesetting enabled by default. + + If in doubt, say "Y". config DRM_I915_FBDEV bool "Enable legacy fbdev support for the modesettting intel driver" @@ -57,9 +56,12 @@ config DRM_I915_FBDEV support. Note that this support also provide the linux console support on top of the intel modesetting driver. + If in doubt, say "Y". + config DRM_I915_PRELIMINARY_HW_SUPPORT bool "Enable preliminary support for prerelease Intel hardware by default" depends on DRM_I915 + default n help Choose this option if you have prerelease Intel hardware and want the i915 driver to support it by default. You can enable such support at @@ -67,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT option changes the default for that module option. If in doubt, say "N". + +config DRM_I915_UMS + bool "Enable userspace modesetting on Intel hardware (DEPRECATED)" + depends on DRM_I915 + default n + help + Choose this option if you still need userspace modesetting. + + Userspace modesetting is deprecated for quite some time now, so + enable this only if you have ancient versions of the DDX drivers. + + If in doubt, say "N". diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 9200c5c47d46..c2e00ed23195 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1007,8 +1007,13 @@ static int __init i915_init(void) driver.driver_features &= ~DRIVER_MODESET; #endif - if (!(driver.driver_features & DRIVER_MODESET)) + if (!(driver.driver_features & DRIVER_MODESET)) { driver.get_vblank_timestamp = NULL; +#ifndef CONFIG_DRM_I915_UMS + /* Silently fail loading to not upset userspace. */ + return 0; +#endif + } return drm_pci_init(&driver, &i915_pci_driver); } -- 1.8.4.3 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] drm/i915: Deprecated UMS support 2013-11-13 21:11 ` [PATCH] " Daniel Vetter @ 2013-11-13 23:18 ` Ville Syrjälä 0 siblings, 0 replies; 14+ messages in thread From: Ville Syrjälä @ 2013-11-13 23:18 UTC (permalink / raw) To: Daniel Vetter; +Cc: Intel Graphics Development On Wed, Nov 13, 2013 at 10:11:25PM +0100, Daniel Vetter wrote: > It's been 5 years since kms support was merged and roughly 4 years > since UMS support was ripped out from userspace drivers. > > Thus far it's not been a big burden to keep the ums paths alive, and > we've made some good progress in better separating it from the kms > code by sprinkling DRIVER_MODESET checks all over the place. > > But now that the drm demidlayering is within reach this changes. I > want to make the driver loading code more robust using devres.c and > other cool tricks. But that doesn't work with ums due to the > shadow-attach trick. Which means we either > a) need to split out a complete ums codebase like radeon has > b) kill it for good. > > The 2nd option is obviously much less work than the first, so I think > it's time to test the waters and see how many people out there still > use ums. > > I've decided that silently failing to initialize the driver (and not > e.g. failing to load the module) is the right thing. That way we > should only get reports from users that actually care about some ums > features (like accelerated gl or support for secondary outputs). > Everyone else will just fall back to the vesa X driver. > > For developers there's a small info level dmesg output. > > The plan is to drop this Kconfig option after 3.16 (so gives us 2 full > releases) and then start killing code for real 2-3 releases > afterwards. That should be more than enough time for users to pipe up. > > Of course if anyone does we need to revisit this plan and maybe go > with option a) above. > > Also enable the KMS support by default in Kconfig and polish the help > texts a bit. > > v2: Add the missing hunk of actual code changes. Oops. (Ville) > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Dave Airlie <airlied@gmail.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/gpu/drm/i915/Kconfig | 24 +++++++++++++++++++----- > drivers/gpu/drm/i915/i915_drv.c | 7 ++++++- > 2 files changed, 25 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index b0f61679c598..b0fa4c4055ee 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -37,12 +37,11 @@ config DRM_I915 > config DRM_I915_KMS > bool "Enable modesetting on intel by default" > depends on DRM_I915 > + default y > help > - Choose this option if you want kernel modesetting enabled by default, > - and you have a new enough userspace to support this. Running old > - userspaces with this enabled will cause pain. Note that this causes > - the driver to bind to PCI devices, which precludes loading things > - like intelfb. > + Choose this option if you want kernel modesetting enabled by default. > + > + If in doubt, say "Y". > > config DRM_I915_FBDEV > bool "Enable legacy fbdev support for the modesettting intel driver" > @@ -57,9 +56,12 @@ config DRM_I915_FBDEV > support. Note that this support also provide the linux console > support on top of the intel modesetting driver. > > + If in doubt, say "Y". > + > config DRM_I915_PRELIMINARY_HW_SUPPORT > bool "Enable preliminary support for prerelease Intel hardware by default" > depends on DRM_I915 > + default n > help > Choose this option if you have prerelease Intel hardware and want the > i915 driver to support it by default. You can enable such support at > @@ -67,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT > option changes the default for that module option. > > If in doubt, say "N". > + > +config DRM_I915_UMS > + bool "Enable userspace modesetting on Intel hardware (DEPRECATED)" > + depends on DRM_I915 > + default n > + help > + Choose this option if you still need userspace modesetting. > + > + Userspace modesetting is deprecated for quite some time now, so > + enable this only if you have ancient versions of the DDX drivers. > + > + If in doubt, say "N". > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 9200c5c47d46..c2e00ed23195 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1007,8 +1007,13 @@ static int __init i915_init(void) > driver.driver_features &= ~DRIVER_MODESET; > #endif > > - if (!(driver.driver_features & DRIVER_MODESET)) > + if (!(driver.driver_features & DRIVER_MODESET)) { > driver.get_vblank_timestamp = NULL; BTW this NULL assignment is pointless since we don't even populate the function pointer until intel_irq_init(). So if you add a patch to kill the NULL assignment first, you could place the entire if block inside the UMS ifndef. But in either case this looks like it does what it says, so: Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > +#ifndef CONFIG_DRM_I915_UMS > + /* Silently fail loading to not upset userspace. */ > + return 0; > +#endif > + } > > return drm_pci_init(&driver, &i915_pci_driver); > } > -- > 1.8.4.3 -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-11-14 0:43 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-11 8:35 [PATCH 0/3] Deprecate legacy crap Daniel Vetter 2013-11-11 8:35 ` [PATCH 1/3] drm/i915: Make AGP=n work even on gen3 Daniel Vetter 2013-11-13 18:59 ` Ville Syrjälä 2013-11-13 20:21 ` Daniel Vetter 2013-11-13 23:24 ` Ville Syrjälä 2013-11-14 0:43 ` Daniel Vetter 2013-11-11 8:35 ` [PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms Daniel Vetter 2013-11-13 19:00 ` Ville Syrjälä 2013-11-13 21:14 ` [PATCH] " Daniel Vetter 2013-11-13 23:20 ` Ville Syrjälä 2013-11-11 8:35 ` [PATCH 3/3] drm/i915: Deprecated UMS support Daniel Vetter 2013-11-13 19:01 ` Ville Syrjälä 2013-11-13 21:11 ` [PATCH] " Daniel Vetter 2013-11-13 23:18 ` Ville Syrjälä
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.