From: Jani Nikula <jani.nikula@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES
Date: Wed, 12 Oct 2022 11:51:48 +0300 [thread overview]
Message-ID: <87mta1whjv.fsf@intel.com> (raw)
In-Reply-To: <20221011-pick-even-ranges-v1-0-1aaea52752ed@intel.com>
On Tue, 11 Oct 2022, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address
> ranges. This should cover most of our needs for _MMIO_PLL3 and such.
> To show what is achieved with the new macro, convert some PLL-related
> macros to use it instead of _MMIO_PLL3.
While there's nothing particularly wrong about the solution when looked
at in isolation, I do have pretty strong reservations on the whole.
We have:
1) _PICK_EVEN() used in _PIPE() and friends
2) _PICK() used in _MMIO_PIPE3() and friends
3) ->pipe_offsets[] etc. adjustment used in _MMIO_PIPE2() and friends
4) ->ddi_index[] mapping proposed in [1]
5) _PICK_EVEN_RANGES() proposed here
Originally we only had the first one, when the hardware was
simpler. Every single addition since then made sense at the time, but if
we add 4 & 5 to the mix, I think it's just too many options.
I think it's time to take a step back and figure out if there's a more
generic approach that could be used.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/108833/
--
Jani Nikula, Intel Open Source Graphics Center
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Subject: Re: [PATCH 0/3] Add _PICK_EVEN_RANGES
Date: Wed, 12 Oct 2022 11:51:48 +0300 [thread overview]
Message-ID: <87mta1whjv.fsf@intel.com> (raw)
In-Reply-To: <20221011-pick-even-ranges-v1-0-1aaea52752ed@intel.com>
On Tue, 11 Oct 2022, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address
> ranges. This should cover most of our needs for _MMIO_PLL3 and such.
> To show what is achieved with the new macro, convert some PLL-related
> macros to use it instead of _MMIO_PLL3.
While there's nothing particularly wrong about the solution when looked
at in isolation, I do have pretty strong reservations on the whole.
We have:
1) _PICK_EVEN() used in _PIPE() and friends
2) _PICK() used in _MMIO_PIPE3() and friends
3) ->pipe_offsets[] etc. adjustment used in _MMIO_PIPE2() and friends
4) ->ddi_index[] mapping proposed in [1]
5) _PICK_EVEN_RANGES() proposed here
Originally we only had the first one, when the hardware was
simpler. Every single addition since then made sense at the time, but if
we add 4 & 5 to the mix, I think it's just too many options.
I think it's time to take a step back and figure out if there's a more
generic approach that could be used.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/108833/
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-10-12 8:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 4:51 [Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES Lucas De Marchi
2022-10-12 4:51 ` Lucas De Marchi
2022-10-12 4:51 ` [Intel-gfx] [PATCH 1/3] drm/i915: Add _PICK_EVEN_RANGES() Lucas De Marchi
2022-10-12 4:51 ` Lucas De Marchi
2022-10-12 5:13 ` [Intel-gfx] " Lucas De Marchi
2022-10-12 5:13 ` Lucas De Marchi
2022-10-12 4:51 ` [Intel-gfx] [PATCH 2/3] drm/i915: Fix coding style on DPLL*_ENABLE defines Lucas De Marchi
2022-10-12 4:51 ` Lucas De Marchi
2022-10-12 4:51 ` [Intel-gfx] [PATCH 3/3] drm/i915: Convert pll macros to _PICK_EVEN_RANGES Lucas De Marchi
2022-10-12 4:51 ` Lucas De Marchi
2022-10-12 5:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add _PICK_EVEN_RANGES Patchwork
2022-10-12 5:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-10-12 5:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-10-12 7:45 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-10-12 8:51 ` Jani Nikula [this message]
2022-10-12 8:51 ` [PATCH 0/3] " Jani Nikula
2022-10-12 19:05 ` [Intel-gfx] " Lucas De Marchi
2022-10-12 19:05 ` Lucas De Marchi
2022-10-22 6:45 ` [Intel-gfx] " Lucas De Marchi
2022-11-11 15:22 ` 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=87mta1whjv.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--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.