On Mon, 22 Jun 2020 at 19:55, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, 22 Jun 2020, Daniel Vetter <daniel@xxxxxxxx> wrote:
> > On Wed, Jun 17, 2020 at 05:42:15PM -0700, Lucas De Marchi wrote:
> >> From: Abdiel Janulgue <abdiel.janulgue@xxxxxxxxxxxxxxx>
> >>
> >> Bspec: 33617, 33617
> >>
> >> Cc: José Roberto de Souza <jose.souza@xxxxxxxxx>
> >> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx>
> >> Cc: Stuart Summers <stuart.summers@xxxxxxxxx>
> >> Cc: Vanshidhar Konda <vanshidhar.r.konda@xxxxxxxxx>
> >> Cc: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
> >> Cc: Aravind Iddamsetty <aravind.iddamsetty@xxxxxxxxx>
> >> Cc: Matt Roper <matthew.d.roper@xxxxxxxxx>
> >> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@xxxxxxxxxxxxxxx>
> >> Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
> >> Reviewed-by: José Roberto de Souza <jose.souza@xxxxxxxxx>
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.h | 7 +++++++
> >> drivers/gpu/drm/i915/i915_pci.c | 12 ++++++++++++
> >> drivers/gpu/drm/i915/intel_device_info.c | 1 +
> >> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> >> 4 files changed, 21 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >> index 2f8057a0b2280..f79c09257eb6b 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -1428,6 +1428,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >> #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
> >> #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
> >> #define IS_ROCKETLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
> >> +#define IS_DG1(dev_priv) IS_PLATFORM(dev_priv, INTEL_DG1)
> >> #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> >> (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
> >> #define IS_BDW_ULT(dev_priv) \
> >> @@ -1556,6 +1557,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >> #define IS_RKL_REVID(p, since, until) \
> >> (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
> >>
> >> +#define DG1_REVID_A0 0x0
> >> +#define DG1_REVID_B0 0x1
> >> +
> >> +#define IS_DG1_REVID(p, since, until) \
> >> + (IS_DG1(p) && IS_REVID(p, since, until))
> >> +
> >> #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp)
> >> #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
> >> #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
> >> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> >> index e5fdf17cd9cdd..58cceeaa0ffa5 100644
> >> --- a/drivers/gpu/drm/i915/i915_pci.c
> >> +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> @@ -896,8 +896,20 @@ static const struct intel_device_info rkl_info = {
> >>
> >> #define GEN12_DGFX_FEATURES \
> >> GEN12_FEATURES, \
> >> + .memory_regions = REGION_SMEM | REGION_LMEM, \
> >
> > This has lmem, and we need a new uapi for that. Last year we discussed a
> > plan to have that behind a very scary compile-time only option, to make
> > absolutely sure no one will start relying on this broken state before we
> > aligned everything. And we know the current status is wrong since this
> > patch series doesn't include any of the lmem specific uapi that's being
> > worked on.
> >
> > But now almost a year passed, so that original plan needs to be
> > renegotiated. Personally I'm not sure the scary compile option makes
> > sense any longer, we're way later, users will soon have real hw, and once
> > they have that they will find ways to enable it and we're potentially
> > screwed. Discussed this also with Joonas last week or so in private, and
> > he shares similar concerns.
> >
> > So I think best option here (since keeping patches out of tree is rarely
> > best option) would be to merge just the display enabling for DG1, but also
> > making sure that we have all the rendering support completely disabled.
> > This would mean:
> > - wedge gpu on startup, just to make sure
> > - drm_driver->num_ioctls = 0 (plus ioctls = NULL)
> > - no setting DRIVER_RENDER and DRIVER_SYNCOBJ, we'd be a pure
> > display-only driver
> >
> > Adding Dave and drm-intel maintainers to quickly hash this out. Thoughts?
>
> I'll defer the decision on lmem to folks who actually know this stuff,
> and focus on display. And from that perspective, I'd like to unblock
> merging the display patches.
>
How does display work without LMEM, I'm assuming you have to scan out
from VRAM on DG1, even if we only have internal non-uapi is this
enough to bring up fbcon?
Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
