dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Rajat Jain <rajatja@google.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: "Sean Paul" <seanpaul@google.com>,
	"David Airlie" <airlied@linux.ie>,
	"Sugumaran Lacshiminarayanan" <slacshiminar@lenovo.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Daniel Thompson" <daniel.thompson@linaro.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Mark Pearson" <mpearson@lenovo.com>,
	"Tomoki Maruichi" <maruichit@lenovo.com>,
	"Jesse Barnes" <jsbarnes@google.com>,
	"Rajat Jain" <rajatxjain@gmail.com>,
	intel-gfx@lists.freedesktop.org, "Mat King" <mathewk@google.com>,
	"José Roberto de Souza" <jose.souza@intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Sean Paul" <sean@poorly.run>,
	"Duncan Laurie" <dlaurie@google.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Pavel Machek" <pavel@denx.de>,
	"Nitin Joshi1" <njoshi1@lenovo.com>
Subject: Re: [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors
Date: Fri, 6 Mar 2020 17:38:53 -0800	[thread overview]
Message-ID: <CACK8Z6HFOpsfhHo=y9Qj_NSdiCGBHsvchZ335mU1BQ5CYQq1VQ@mail.gmail.com> (raw)
In-Reply-To: <87tv31om53.fsf@intel.com>

On Fri, Mar 6, 2020 at 1:42 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Thu, 05 Mar 2020, Rajat Jain <rajatja@google.com> wrote:
> > On Thu, Mar 5, 2020 at 1:41 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> >>
> >> On Wed, 04 Mar 2020, Rajat Jain <rajatja@google.com> wrote:
> >> 1) See if we can postpone creating and attaching properties to connector
> >> ->late_register hook. (I didn't have the time to look into it yet, at
> >> all.)
> >
> > Apparently not. The drm core doesn't like to add properties in
> > late_register() callback. I just tried it and get this warning:
>
> I kind of had a feeling this would be the case, thanks for checking.

Thinking about it again, it looks like there is a difference in
creating a property and attaching a property. I'm wondering if drm
would let me (unconditionally) create a property before registering,
and attach it in late_register() only in case a privacy screen is
detected. (If not present, I can destroy the property in
late_register()). If this approach sound more promising, I can try it
out.

>
> >> 2) Provide a way to populate connector->acpi_device_id and
> >> connector->acpi_handle on a per-connector basis. At least the device id
> >> remains constant for the lifetime of the drm_device
> >
> > Are you confirming that the connector->acpi_device_id remains constant
> > for the lifetime of the drm_device, as calculated in
> > intel_acpi_device_id_update()?  Even in the face of external displays
> > (monitors) being connected and disconnected during the lifetime of the
> > system? If so, then I think we can have a solution.
>
> First I thought so. Alas it does not hold for DP MST, where you can have
> connectors added and removed dynamically. I think we could ensure they
> stay the same for all other connectors though. I'm pretty sure this is
> already the case; they get added/removed after all others.
>
> Another thought, from the ACPI perspective, I'm not sure the dynamically
> added/removed DP MST connectors should even have acpi handles. But
> again, tying all this together with ACPI stuff is not something I am an
> expert on.

I propose that we:

1) Maintain a display_index[] array within the drm_dev, and increment
as connectors are added.
2) Initialize connector->acpi_device_id and and connector->acpi_handle
while registering (one time per connector).
3) Remove the code to update acpi_device_id on every resume.

It doesn't look like anyone on the DP MST side has cared for ACPI so
far, so I doubt if we can do anything that might break MST currently.
In other words, the above should not make things any worse for MST, if
not better. For connectors other than MST, this should allow them to
get ACPI handle and play with it, if they need.

WDYT?

Thanks,

Rajat

>
> >> (why do we keep
> >> updating it at every resume?!) but can we be sure ->acpi_handle does
> >> too? (I don't really know my way around ACPI.)
> >
> > I don't understand why this was being updated on every resume in that
> > case (this existed even before my patchset). I believe we do not need
> > it. Yes, the ->acpi_handle will not change if the ->acpi_device_id
> > does not change. I believe the way forward should then be to populate
> > connector->acpi_device_id and connector->acpi_handle ONE TIME at the
> > time of connector init (and not update it on every resume). Does this
> > sound ok?
>
> If a DP MST connector gets removed, should the other ACPI display
> indexes after that shift, or remain the same? I really don't know.
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-03-07 10:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200305012338.219746-1-rajatja@google.com>
2020-03-05  1:23 ` [PATCH v6 1/3] intel_acpi: Rename drm_dev local variable to dev Rajat Jain
2020-03-05  9:14   ` Jani Nikula
2020-03-05  1:23 ` [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors Rajat Jain
2020-03-05  9:40   ` Jani Nikula
2020-03-06  3:27     ` Rajat Jain
2020-03-06  9:42       ` Jani Nikula
2020-03-07  1:38         ` Rajat Jain [this message]
2020-03-10  0:09           ` Rajat Jain
2020-03-05  1:23 ` [PATCH v6 3/3] drm/i915: Add support for integrated privacy screens Rajat Jain
2020-03-05 10:01   ` Jani Nikula
2020-03-06  3:35     ` Rajat Jain
2020-03-06 10:15       ` Jani Nikula
2020-03-07  1:27         ` Rajat Jain
2020-03-05  1:19 [PATCH v6 1/3] intel_acpi: Rename drm_dev local variable to dev Rajat Jain
2020-03-05  1:19 ` [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors Rajat Jain

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='CACK8Z6HFOpsfhHo=y9Qj_NSdiCGBHsvchZ335mU1BQ5CYQq1VQ@mail.gmail.com' \
    --to=rajatja@google.com \
    --cc=airlied@linux.ie \
    --cc=corbet@lwn.net \
    --cc=daniel.thompson@linaro.org \
    --cc=dlaurie@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jose.souza@intel.com \
    --cc=jsbarnes@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maruichit@lenovo.com \
    --cc=mathewk@google.com \
    --cc=mpearson@lenovo.com \
    --cc=njoshi1@lenovo.com \
    --cc=pavel@denx.de \
    --cc=rajatxjain@gmail.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sean@poorly.run \
    --cc=seanpaul@google.com \
    --cc=slacshiminar@lenovo.com \
    --cc=thierry.reding@gmail.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;
as well as URLs for NNTP newsgroup(s).