On Mon, May 9, 2016 at 3:13 PM, Chad Versace wrote:
> On Mon 09 May 2016, Eric Engestrom wrote:
> > On Sun, May 01, 2016 at 09:39:58PM -0700, Jason Ekstrand wrote:
> > > On May 1, 2016 6:04 PM, "Kenneth Graunke"
> wrote:
> > > > On Sunday, May 1, 2016 9:51:00 AM PDT Emil Velikov wrote:
> > > > >
Hi,
I'm looking for missing documentation of the offsets to the PCH
registers on Intel 2011 processors.
https://01.org/sites/default/files/documentation/snb_ihd_os_vol3_part3.pdf
says to consult a spreadsheet, which I can't find on that site:
--
1.1.4 Register Instances and Address Offsets
T
On Fri, May 06, 2016 at 02:42:46PM -0400, Lyude Paul wrote:
> On Fri, 2016-05-06 at 14:12 -0400, Lyude Paul wrote:
> > On Thu, 2016-04-21 at 16:17 -0700, Matt Roper wrote:
> > >
> > > Now that we're properly pre-allocating the DDB during the atomic check
> > > phase and we trust that the allocatio
For a detailed explanation of this series, please see the original cover letter:
https://lists.freedesktop.org/archives/intel-gfx/2016-April/091293.html
This version is pretty much the same as v3 except that it should also fix the
problems that appear if the BIOS programs bogus/unexpected DDB va
Reorganize the nested structures and unions we have for pipe watermark
data in intel_crtc_state so that platform-specific data can be added in
a more sensible manner (and save a bit of memory at the same time).
The change basically changes the organization from:
union {
st
This will be important when we start calculating CRTC data rates for
in-flight CRTC states since it will allow us to calculate the total data
rate without needing to grab the plane state for any planes that aren't
updated by the transaction.
Signed-off-by: Matt Roper
Reviewed-by: Maarten Lankhors
Our skl_get_total_relative_data_rate() function gets passed a crtc state
object to calculate the data rate for, but it currently always looks
up the committed plane states that correspond to that CRTC. Let's
check whether the CRTC state is an in-flight state (meaning
cstate->state is non-NULL) and
When we added atomic watermarks, we added a new display vfunc
'compute_pipe_wm' that is used to compute any pipe-specific watermark
information that we can at atomic check time. This was a somewhat poor
naming choice since we already had a 'skl_compute_pipe_wm' function that
doesn't quite fit this
This will eventually allow us to re-use old values without
re-calculating them for unchanged planes (which also helps us avoid
re-grabbing extra plane states).
v2:
- Drop unnecessary memset's; they were meant for a later patch (which
got reworked anyway to not need them, but were mis-rebased
For the purposes of DDB re-allocation we need to know whether a
transaction changes the list of CRTC's that are active. While
state->modeset could be used for this purpose, that would be slightly
too aggressive since it would lead us to re-allocate the DDB when a
CRTC's mode changes, but not its f
We eventually want to calculate watermark values at atomic 'check' time
instead of atomic 'commit' time so that any requested configurations
that result in impossible watermark requirements are properly rejected.
The first step along this path is to allocate the DDB at atomic 'check'
time. As we p
SKL-style platforms can't fully trust the watermark/DDB settings
programmed by the BIOS and need to do extra sanitization on their first
atomic update. Add a flag to dev_priv that is set during hardware
readout and cleared at the end of the first commit.
Note that for the somewhat common case whe
Now that we're properly pre-allocating the DDB during the atomic check
phase and we trust that the allocation is appropriate, let's actually
use the allocation computed and not duplicate that work during the
commit phase.
v2:
- Significant rebasing now that we can use cached data rates and
min
Calculate the DDB blocks needed to satisfy the current atomic
transaction at atomic check time. This is a prerequisite to calculating
SKL watermarks during the 'check' phase and rejecting any configurations
that we can't find valid watermarks for.
Due to the nature of DDB allocation, it's possibl
Slightly easier to work with than an array of bools.
Signed-off-by: Matt Roper
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dr
In a future patch we'll want to calculate plane watermarks for in-flight
atomic state rather than the already-committed state.
Signed-off-by: Matt Roper
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
dif
Moving watermark calculation into the check phase will allow us to to
reject display configurations for which there are no valid watermark
values before we start trying to program the hardware (although those
tests will come in a subsequent patch).
Another advantage of moving this calculation to t
In an upcoming patch we'll move this calculation to the atomic 'check'
phase so that the display update can be rejected early if no valid
watermark programming is possible.
v2:
- Drop intel_pstate_for_cstate_plane() helper and add note about how
the code needs to evolve in the future if we sta
We calculate the watermark config into intel_atomic_state and then save
it into dev_priv, but never actually use it from there. This is
left-over from some early ILK-style watermark programming designs that
got changed over time.
Signed-off-by: Matt Roper
Reviewed-by: Maarten Lankhorst
---
dri
If we can't find any valid level 0 watermark values for the requested
atomic transaction, reject the configuration before we try to start
programming the hardware.
v2:
- Add extra debugging output when we reject level 0 watermarks so that
we can more easily debug how/why they were rejected.
C
Once we move watermark calculation to the atomic check phase, we'll want
to start rejecting display configurations that exceed out watermark
limits. At the moment we just assume that there's always a valid set of
watermarks, even though this may not actually be true. Let's prepare by
passing retu
On ma, 2016-05-09 at 17:39 +0100, Chris Wilson wrote:
> arch/x86/kernel/early-quirks.c: In function ‘intel_graphics_stolen’:
> arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects
> argument of type ‘long long unsigned int’, but argument 2 has type
> ‘phys_addr_t’ [-Wformat=]
>
== Series Details ==
Series: series starting with [1/2] drm/atomic: Add a way to call remove_fb
atomically, v2.
URL : https://patchwork.freedesktop.org/series/6906/
State : failure
== Summary ==
Series 6906v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6906/rev
Hi Daniel,
2016년 04월 27일 20:38에 Daniel Vetter 이(가) 쓴 글:
> It's an optional hook. Might be needed for frontbuffer rendering on
> manual upload displays, but a simple TODO doesn't explain at all what
> needs to be done or why.
We have a plan for partial update support but not now yet. Picked it up.
2016년 04월 27일 02:29에 Daniel Vetter 이(가) 쓴 글:
> No dev->struct_mutex anywhere to be seen.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --
101 - 125 of 125 matches
Mail list logo
