From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 09/11] drm/i915: Turn intel_digital_port_connected() in a vfunc
Date: Tue, 4 Feb 2020 23:07:21 +0200 [thread overview]
Message-ID: <20200204210721.GF13686@intel.com> (raw)
In-Reply-To: <87r1zk9cgt.fsf@intel.com>
On Tue, Jan 28, 2020 at 11:06:42AM +0200, Jani Nikula wrote:
> On Tue, 21 Jan 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
> > index 3da166054788..cf0df6f18734 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> > @@ -116,6 +116,12 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
> > void intel_dp_hdr_metadata_enable(struct intel_dp *intel_dp,
> > const struct intel_crtc_state *crtc_state,
> > const struct drm_connector_state *conn_state);
> > +bool cpt_digital_port_connected(struct intel_encoder *encoder);
> > +bool spt_digital_port_connected(struct intel_encoder *encoder);
> > +bool ivb_digital_port_connected(struct intel_encoder *encoder);
> > +bool bdw_digital_port_connected(struct intel_encoder *encoder);
> > +bool bxt_digital_port_connected(struct intel_encoder *encoder);
> > +bool icp_digital_port_connected(struct intel_encoder *encoder);
>
> Please find a way to not expose a plethora of platform specific
> functions from files. I want to take things to the completely opposite
> direction.
Many of these do disappear in the next patch. Still, I was letting
this idea simmer a bit in case I'd actually come up with a good
approach, alas no inspiration has occurred. I think we have three
options:
1) keep everyting hidden in intel_dp.c and expose some kind of
intel_dig_port_init() thing that we call from the ddi code.
The reason I don't really like this is I've been thinking of
stuffing all the function pointers into some const vtables
which would probably be mostly populated by stuff from
intel_ddi.c. So we'd end up in the exact opposite situation
where ddi code would have to exposes functions to intel_dp.c.
2) Store the hpd register in intel_encoder/dig_port/etc. so we could
unify the ilk/ivb/bdw/pch functions into a single function. But
since we still need special sauce for the TC ports we'd still want
the vfunc. And since we do have the vfunc storing the hpd register
offset feels rather redundant.
3) Duplicate two of the functions in intel_ddi.c:
ivb->hsw and pch->lpt (or whatever we call it), and move
the bdw function over entirely. The duplication seems a
bit silly, but might actually be the least annoying approach.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-02-04 21:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 17:10 [Intel-gfx] [PATCH 00/11] drm/i915: Hotplug cleanups Ville Syrjala
2020-01-21 17:10 ` [Intel-gfx] [PATCH 01/11] drm/i915: Prefer intel_connector over drm_connector in hotplug code Ville Syrjala
2020-01-22 9:50 ` Jani Nikula
2020-01-21 17:10 ` [Intel-gfx] [PATCH 02/11] drm/i915: Introduce intel_connector_hpd_pin() Ville Syrjala
2020-01-28 8:22 ` Jani Nikula
2020-01-21 17:10 ` [Intel-gfx] [PATCH 03/11] drm/i915/crt: Configure connector->polled and encoder->hpd_pin consistently Ville Syrjala
2020-01-28 8:23 ` Jani Nikula
2020-01-21 17:10 ` [Intel-gfx] [PATCH 04/11] drm/i915/hpd: Replace the loop-within-loop with two independent loops Ville Syrjala
2020-01-21 17:10 ` [Intel-gfx] [PATCH 05/11] drm/i915: Mark all HPD capabled connectors as such Ville Syrjala
2020-01-21 17:10 ` [Intel-gfx] [PATCH 06/11] drm/i915: Mark ns2501 as LVDS without a fixed mode Ville Syrjala
2020-01-28 8:42 ` Jani Nikula
2020-01-21 17:10 ` [Intel-gfx] [PATCH 07/11] drm/i915/dvo: Mark TMDS DVO connectors as polled Ville Syrjala
2020-01-28 8:45 ` Jani Nikula
2020-01-21 17:10 ` [Intel-gfx] [PATCH 08/11] drm/i915: Sprinkle missing commas Ville Syrjala
2020-01-28 8:36 ` Jani Nikula
2020-01-21 17:10 ` [Intel-gfx] [PATCH 09/11] drm/i915: Turn intel_digital_port_connected() in a vfunc Ville Syrjala
2020-01-21 19:44 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2020-01-28 9:06 ` Jani Nikula
2020-02-04 21:07 ` Ville Syrjälä [this message]
2020-01-21 17:10 ` [Intel-gfx] [PATCH 10/11] drm/i915: Stash hpd status bits under dev_priv Ville Syrjala
2020-01-21 17:11 ` [Intel-gfx] [PATCH 11/11] drm/i915: Use stashed away hpd isr bits in intel_digital_port_connected() Ville Syrjala
2020-01-21 19:18 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Hotplug cleanups Patchwork
2020-01-21 20:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hotplug cleanups (rev2) Patchwork
2020-01-23 3:35 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-01-23 18:07 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
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=20200204210721.GF13686@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox