From: Jani Nikula <jani.nikula@intel.com>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [RFC 0/3] Display uncore
Date: Wed, 30 Oct 2019 08:11:08 +0200 [thread overview]
Message-ID: <87o8xykbk3.fsf@intel.com> (raw)
In-Reply-To: <34a277b3-820b-f077-b7e8-b4d633f30576@intel.com>
On Tue, 29 Oct 2019, Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> wrote:
> On 10/29/19 2:23 AM, Jani Nikula wrote:
>> On Wed, 07 Aug 2019, Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> wrote:
>>> I've been trying to identify MMIO ranges to clearly define what belongs
>>> to display_uncore to do a check on access, but there are lots of
>>> exceptions and differences across gens (with a few more coming with TGL),
>>> so I don't think that's a viable way. The alternative option implemented
>>> here is to differentiate the register by type, which should ensure we
>>> never mix them up, but at the cost of a more complex transition.
>>>
>>> Thoughts? I'm very open to (and I actually hope for) better ideas.
>>
>> Has there been any progress in this front lately, or have I just missed
>> it?
>>
>
> No progress on the ML. I've been locally trying on and off to break
> i915_reg.h in more manageable chunks to be able to more easily mark the
> display registers, but I keep finding special cases, especially around
> VLV/CHV. I'll try to prioritize this task more and get something out, at
> least as a RFC.
Okay. As you saw, I decided to start moving forward with display uncore
helpers [1]. We'll need them anyway, and we can add the display checks
there afterwards. If anything, they should make your job easier, not
harder.
BR,
Jani.
[1] http://patchwork.freedesktop.org/patch/msgid/20191029105156.21658-1-jani.nikula@intel.com
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [Intel-gfx] [RFC 0/3] Display uncore
Date: Wed, 30 Oct 2019 08:11:08 +0200 [thread overview]
Message-ID: <87o8xykbk3.fsf@intel.com> (raw)
Message-ID: <20191030061108._wVJHezsvFOy_ruxsimvzeeywOfBl5ufcbzoXS-Psb4@z> (raw)
In-Reply-To: <34a277b3-820b-f077-b7e8-b4d633f30576@intel.com>
On Tue, 29 Oct 2019, Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> wrote:
> On 10/29/19 2:23 AM, Jani Nikula wrote:
>> On Wed, 07 Aug 2019, Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> wrote:
>>> I've been trying to identify MMIO ranges to clearly define what belongs
>>> to display_uncore to do a check on access, but there are lots of
>>> exceptions and differences across gens (with a few more coming with TGL),
>>> so I don't think that's a viable way. The alternative option implemented
>>> here is to differentiate the register by type, which should ensure we
>>> never mix them up, but at the cost of a more complex transition.
>>>
>>> Thoughts? I'm very open to (and I actually hope for) better ideas.
>>
>> Has there been any progress in this front lately, or have I just missed
>> it?
>>
>
> No progress on the ML. I've been locally trying on and off to break
> i915_reg.h in more manageable chunks to be able to more easily mark the
> display registers, but I keep finding special cases, especially around
> VLV/CHV. I'll try to prioritize this task more and get something out, at
> least as a RFC.
Okay. As you saw, I decided to start moving forward with display uncore
helpers [1]. We'll need them anyway, and we can add the display checks
there afterwards. If anything, they should make your job easier, not
harder.
BR,
Jani.
[1] http://patchwork.freedesktop.org/patch/msgid/20191029105156.21658-1-jani.nikula@intel.com
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-10-30 6:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 1:44 [RFC 0/3] Display uncore Daniele Ceraolo Spurio
2019-08-08 1:44 ` [RFC 1/3] drm/i915: split out uncore_mmio_debug Daniele Ceraolo Spurio
2019-08-08 13:08 ` Mika Kuoppala
2019-08-08 16:43 ` Daniele Ceraolo Spurio
2019-08-08 16:59 ` Chris Wilson
2019-08-08 1:44 ` [RFC 2/3] drm/i915: introduce display_uncore Daniele Ceraolo Spurio
2019-08-08 1:44 ` [RFC 3/3] drm/i915: convert a couple of registers to _DE_MMIO Daniele Ceraolo Spurio
2019-08-08 2:05 ` ✗ Fi.CI.CHECKPATCH: warning for Display uncore (rev3) Patchwork
2019-08-08 2:07 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-08-08 2:27 ` ✓ Fi.CI.BAT: success " Patchwork
2019-08-08 13:29 ` [RFC 0/3] Display uncore Chris Wilson
2019-08-08 13:58 ` Jani Nikula
2019-08-08 16:47 ` Daniele Ceraolo Spurio
2019-08-08 17:13 ` Lucas De Marchi
2019-08-09 7:58 ` Jani Nikula
2019-08-08 14:40 ` ✗ Fi.CI.IGT: failure for Display uncore (rev3) Patchwork
2019-10-29 9:23 ` [RFC 0/3] Display uncore Jani Nikula
2019-10-29 9:23 ` [Intel-gfx] " Jani Nikula
2019-10-29 21:18 ` Daniele Ceraolo Spurio
2019-10-29 21:18 ` [Intel-gfx] " Daniele Ceraolo Spurio
2019-10-30 6:11 ` Jani Nikula [this message]
2019-10-30 6:11 ` Jani Nikula
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=87o8xykbk3.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@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.