Manasi Navare [Wed, 28 Feb 2018 22:31:50 +0000 (14:31 -0800)]
drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array
dp_rates[] array is a superset of all the link rates supported
by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
to the set of link rates supported by sink. This patch adds this rate
to dp_rates[] array that gets used to populate the sink_rates[]
array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register.
v2:
* Rebased on top of Jani's localized rates patch
Jani Nikula [Tue, 27 Feb 2018 10:59:11 +0000 (12:59 +0200)]
drm/i915/dp: move link rate arrays where they're used
Localize link rate arrays by moving them to the functions where they're
used. Further clarify the distinction between source and sink
capabilities. Split pre and post Haswell arrays, and get rid of the
array size arithmetics. Use a direct rate value in the paranoia case of
no common rates find.
Ville Syrjälä [Thu, 22 Feb 2018 18:10:33 +0000 (20:10 +0200)]
drm/i915: Consult aux_ch instead of port in ->get_aux_clock_divider()
While it seems totally unlikely that any system would mix a cpu/north
aux channel with a pch/south port (or vice versa) we should still
consult intel_dp->aux_ch rather than encoder->port when figuring out
which clock is actually used by the aux ch.
Although we protect the request itself, we don't lock inside
intel_engine_dump() and so the request maybe retired as we peek into it.
One consequence is that the request->ctx may be freed before we
dereference it, leading to a use-after-free. Replace the hw_id we are
peeking from inside request->ctx with the request->fence.context, with
which we can still track from which context the request originated
(although to tie to HW reports requires a little more legwork, but is
good enough to follow the GEM traces).
Currently, BXT_PP is hardcoded with value '0'.
It practically disabled eDP backlight on MRB (BXT) platform.
This patch will tell which BXT_PP registers (there are two set of
PP_CONTROL in the spec) to be used as defined in VBT (Video Bios Timing
table) and this will enabled eDP backlight controller on MRB (BXT)
platform.
v2:
- Remove unnecessary information in commit message.
- Assign vbt.backlight.controller to a backlight_controller variable and
return the variable value.
v3:
- Rebased to latest code base.
- updated commit title.
Chris Wilson [Tue, 27 Feb 2018 21:18:16 +0000 (21:18 +0000)]
drm/i915: Repeat the GEM_BUG_ON message in the ftrace log
As the ftrace log is overflowing the pstore capture, we lose the last
gasps from dmesg which includes the GEM_BUG_ON function:line and condition
that failed. Vital information for tracking down the bug, so append it to
the frace log as well.
Rodrigo Vivi [Tue, 27 Feb 2018 21:29:13 +0000 (13:29 -0800)]
drm/i915/psr: Don't avoid PSR when PSR2 conditions are not met.
We can still use PSR1 when PSR2 conditions are not met.
So, let's split the check in a way that we make sure has_psr
gets set independently of PSR2 criteria.
v2: Duh! Handle proper return to avoid breaking PSR2.
v3: (DK):
- better name for psr2 conditions check function
- Don't remove FIXME block and psr2.support check.
- Add a debug message to show us what PSR or PSR2 is
getting enabled now we have ways to enabled PSR on
PSR2 panels.
- s/PSR2 disabled/PSR2 not enabled
drm/i915/psr: Check for power state control capability.
eDP spec says - "If PSR/PSR2 is supported, the SET_POWER_CAPABLE bit in the
EDP_GENERAL_CAPABILITY_1 register (DPCD Address 00701h, bit d7) must be set
to 1."
Reject PSR on panels without this cap bit set as such panels cannot be
controlled via SET_POWER & SET_DP_PWR_VOLTAGE register and the DP source
needs to be able to do that for PSR.
Thanks to Nathan for debugging this.
Panel cap checks like this can be done just once, let's fix this
when PSR dpcd init movement lands.
drm/i915/frontbuffer: Mark frontbuffer flush and invalidate with might_sleep()
Frontbuffer flush and invalidate call psr, fbc and drrs functions that use
mutexes but they can be called in atomic contexts in the fbdev path. The
point where the spinlocks are acquired is up in the call stack that is not
entirely easy to spot, so annotate with might_sleep().
PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain
for AUX-A enables DC_OFF well too. This is not required, so add a new
AUX_IO_A domain for AUX-A to allow DC states to remain enabled. Other AUX
channels re-use the existing AUX domains.
v4: Reword comment (Rodrigo and Ville)
Rename _get and _put functions to include aux_io substring(Rodrigo)
Remove unnecessary diff that got included.
v3: Extract aux domain selection into a function (Ville)
v2: Add AUX IO domain only for AUX-A
Rebased on top of Ville's AUX series.
Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180223221520.18464-1-dhinakaran.pandiyan@intel.com
Michał Winiarski [Mon, 26 Feb 2018 16:37:59 +0000 (17:37 +0100)]
drm/i915/guc: Fill preempt context once at init time
Since we're inhibiting context save of preempt context, we're no longer
tracking the position of HEAD/TAIL. With GuC, we're adding a new
breadcrumb for each preemption, which means that the HW will do more and
more breadcrumb writes. Eventually the ring is filled, and we're
submitting the preemption context with HEAD==TAIL==0, which won't result
in breadcrumb write, but will trigger hangcheck instead.
Instead of writing a new preempt breadcrumb for each preemption, let's
just fill the ring once at init time (which also saves a couple of
instructions in the tasklet).
v2: Assert that context save restore is inhibited, don't assert on ring
alignment. (Chris)
v3: Cleanup checkpatch.
Fixes: 517aaffe0c1b ("drm/i915/execlists: Inhibit context save/restore for the fake preempt context") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180226163800.21745-1-michal.winiarski@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Manasi Navare [Tue, 27 Feb 2018 03:11:15 +0000 (19:11 -0800)]
drm/i915/dp: Fix the order of platforms for setting DP source rates
The usual if ladder order should be from newest to oldest
platform. However the CNL conditional statement was misplaced.
This patch sets the DP source for platforms starting from the newest
to oldest.
Chris Wilson [Thu, 22 Feb 2018 14:22:29 +0000 (14:22 +0000)]
drm/i915/preemption: Allow preemption between submission ports
Sometimes we need to boost the priority of an in-flight request, which
may lead to the situation where the second submission port then contains
a higher priority context than the first and so we need to inject a
preemption event. To do so we must always check inside
execlists_dequeue() whether there is a priority inversion between the
ports themselves as well as the head of the priority sorted queue, and we
cannot just skip dequeuing if the queue is empty.
As Michał noted, this doesn't simply extend to handling more than 2-port
submission, as we may need to reorder within the array of executing
requests which themselves are lower priority than the first. A task for
later!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180222142229.14517-1-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Ville Syrjälä [Thu, 22 Feb 2018 18:10:31 +0000 (20:10 +0200)]
drm/i915: Nuke aux regs from intel_dp
Just store function pointers that give us the correct register offsets
instead of storing the register offsets themselves. Slightly less
efficient perhaps but saves a few bytes and better matches how we do
things elsewhere.
Ville Syrjälä [Thu, 22 Feb 2018 18:10:30 +0000 (20:10 +0200)]
drm/i915: Add enum aux_ch and clean up the aux init to use it
Since we no longer have a 1:1 correspondence between ports and AUX
channels, let's give AUX channels their own enum. Makes it easier
to tell the apples from the oranges, and we get rid of the
port E AUX power domain FIXME since we now derive the power domain
from the actual AUX CH.
v2: Rebase due to AUX F
v3: Split out the power domain fix (Rodrigo)
Ville Syrjälä [Wed, 21 Feb 2018 16:02:35 +0000 (18:02 +0200)]
drm/i915: Add a FIXME about FBC vs. fence. 90/270 degree rotation
Currently the FBC code doesn't handle the 90/270 degree rotated case
correctly. We would need the GTT tracking to monitor the fence on the
normal GTT view (the rotated view doesn't even have a fence). Not quite
sure how we should program the fence Y offset etc. in that case. For now
we'll end up disabling FBC with 90/270 degree rotation. Add a FIXME
to remind people about this fact.
v2: Reword the text (Chris)
Move the FIXME to the fbc code
Ville Syrjälä [Wed, 21 Feb 2018 16:02:33 +0000 (18:02 +0200)]
drm/i915: Require fence only for FBC capable planes
As only a subset of primary planes are FBC capable there's no need
to waste fences on all of them. So let's skip the fence if the plane
isn't even fbc capable.
In the future we might extend this to skip the fence even for FBC
capable planes if the crtc and/or plane state isn't suitable
for FBC.
Ville Syrjälä [Wed, 21 Feb 2018 17:31:01 +0000 (19:31 +0200)]
drm/i915: Clean up fbc vs. plane checks
Let's record the information whether a plane can do fbc or not under
struct inte_plane.
v2: Rebase due to i9xx_plane_id
Handle BDW/HSW correctly
v3: Move inte_fbc_init() back since we depend on it happening
even with i915.disable_display, and populate
fbc->possible_framebuffer_bits directly from the
plane init code instead
v4: Add note about plane A being tied to pipe A on HSW+
Ville Syrjälä [Wed, 21 Feb 2018 18:48:07 +0000 (20:48 +0200)]
drm/i915: Only pin the fence for primary planes (and gen2/3)
Currently we pin a fence on every plane doing tiled scanout. The
number of planes we have available is fast apporaching the number
of fences so we really should stop wasting them. Only FBC needs
the fence on gen4+, so let's use fences only for the primary planes
on those platforms.
v2: drop the tiling check from plane_uses_fence() as the obj is
NULL during initial_plane_config() and we don't rally need the
check since i915_vma_pin_fence() does the check anyway
Johnson Lin [Tue, 30 Jan 2018 15:51:29 +0000 (21:21 +0530)]
drm/i915: Fix Limited Range Color Handling
Some panels support limited range output (16-235) compared
to full range RGB values (0-255). Also userspace can control
the RGB range using "Broadcast RGB" property. Currently the
code to handle full range to limited range is broken. This
patch fixes the same by properly scaling down all the full
range co-efficients with limited range scaling factor.
v2: Fixed Ville's review comments.
v3: Changed input to const and used correct data types as
suggested by Ville
drm/i915/hsw: add missing disabled EUs registers reads
It turns out that HSW has a register that tells us how many EUs are
disabled per half-slice (roughly a similar notion to subslice). We
didn't read those registers so far as most userspace drivers didn't
need those values prior to Gen8, but an internal library would like to
have access to this.
Since we already have the getparam interface, there is no harm in
exposing this.
Paulo Zanoni [Tue, 20 Feb 2018 15:37:52 +0000 (17:37 +0200)]
drm/i915/icl: Add the ICL PCI IDs
This is the current PCI ID list in our documentation.
Let's leave the _gt#_ part out for now since our current documentation
is not 100% clear and we don't need this info now anyway.
v2: Use the new ICL_11 naming (Kelvin Gardiner).
v3: Latest IDs as per BSpec (Oscar).
v4: Make it compile (Paulo).
v5: Remove comments (Lucas).
v6: Multile rebases (Paulo).
v7: Rebase (Mika)
Reviewed-by: Anuj Phogat <anuj.phogat@intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180220153755.13509-1-mika.kuoppala@linux.intel.com
Chris Wilson [Wed, 21 Feb 2018 13:32:36 +0000 (13:32 +0000)]
drm/i915/execlists: Remove the ring advancement under preemption
Load an empty ringbuffer for preemption, ignoring the lite-restore
workaround as we know the preempt context is always idle before preemption.
Note that after some digging by Michal Winiarski, we found that
RING_HEAD is no longer being updated (due to inhibiting context save
restore) so this patch is already in effect!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221133236.29402-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 21 Feb 2018 09:56:36 +0000 (09:56 +0000)]
drm/i915: Rename drm_i915_gem_request to i915_request
We want to de-emphasize the link between the request (dependency,
execution and fence tracking) from GEM and so rename the struct from
drm_i915_gem_request to i915_request. That is we may implement the GEM
user interface on top of requests, but they are an abstraction for
tracking execution rather than an implementation detail of GEM. (Since
they are not tied to HW, we keep the i915 prefix as opposed to intel.)
A corollary to contracting the type name, we also harmonise on using
'rq' shorthand for local variables where space if of the essence and
repetition makes 'request' unwieldy. For globals and struct members,
'request' is still much preferred for its clarity.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221095636.6649-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Daniel Vetter [Tue, 20 Feb 2018 13:20:17 +0000 (14:20 +0100)]
drm/todo: i915 could use device_link_add
Noticed while reading some unrelated patches. Unfortunately Imre's
patch to add our early/late hooks predated the device_link
infrastructure by 2 years.
Tvrtko Ursulin [Tue, 20 Feb 2018 10:47:42 +0000 (10:47 +0000)]
drm/i915: Make global seqno known in i915_gem_request_execute tracepoint
Commit fe49789fab97 ("drm/i915: Deconstruct execute fence") re-arranged
the code and moved the i915_gem_request_execute tracepoint to before the
global seqno is assigned to the request.
We need to move the tracepoint a bit later so this information is once
again available.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: fe49789fab97 ("drm/i915: Deconstruct execute fence") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180220104742.565-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Tue, 20 Feb 2018 13:42:08 +0000 (13:42 +0000)]
drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced
Rather than trusting the cached value of plane_state->vma->fence to
imply whether the plane_state itself holds a reference on the
framebuffer's fence, use the information provided in the
plane_state->flags (PLANE_HAS_FENCE). Note that we still assume that FBC
is entirely bounded by the plane_state active life span; it's not clear
if that is a safe assumption.
Chris Wilson [Tue, 20 Feb 2018 13:42:07 +0000 (13:42 +0000)]
drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning
Use the information about the fence state from the time of pinning to
determine if the fbdev writes are going through a fence. This avoids any
confusion in cases where the fence may appear or disappear unconnected
to the use by fbdev.
Chris Wilson [Tue, 20 Feb 2018 13:42:06 +0000 (13:42 +0000)]
drm/i915: Move the policy for placement of the GGTT vma into the caller
Currently we make the unilateral decision inside
i915_gem_object_pin_to_display() where the VMA should resided (inside
the fence and mappable region or above?). This is not our decision to
make as it impacts on how the display engine can use the resulting
scanout object, and it would rather instruct us where to place the VMA so
that it can enable the features it wants. As such, make the pin flags an
argument to i915_gem_object_pin_to_display() and control them from
intel_pin_and_fence_fb_obj()
Whilst taking control of the mapping for ourselves, start tracking how
we use it to avoid trying to free a fence we never claimed:
Chris Wilson [Tue, 20 Feb 2018 13:42:05 +0000 (13:42 +0000)]
drm/i915: Also check view->type for a normal GGTT view
We cannot simply use !view as shorthand for all normal GGTT views as a
few callers will always populate a i915_ggtt_view struct and set the
type to NORMAL instead. So check for (!view || view->type == NORMAL)
inside i915_gem_object_ggtt_pin().
Ville Syrjälä [Tue, 30 Jan 2018 20:38:02 +0000 (22:38 +0200)]
drm/i915: Set the primary plane pipe select bits on gen4
i965 and g4x still have the pipe select bits in the plane control
registers, they're just hardcoded to select a specific pipe. However
plane C on i965 can still move between the pipes, thus we should
program the pipe select bits on i965 if we want to expose plane C
some day.
Since there is no harm in programming the bits on any plane on
i965/g4x let's just always set them. This will also make our
pre-computed register value match what the hardware register
would read, should we want to cross check the two.
Ville Syrjälä [Tue, 30 Jan 2018 20:38:01 +0000 (22:38 +0200)]
drm/i915: Don't set cursor pipe select bits on g4x+
G4x cursor control registers still allow us to write to the pipe select
bits even though cursors are supposed to be fixed to a specific pipe.
Bspec tells us that we should only ever write 0 to these bits. Let's
follow that recommendation. On ilk+ the bits become hardwired to 0.
Also looks like ICL repurposes these bits for some other use, so
we had better stop setting them to bogus values there.
Ville Syrjälä [Wed, 24 Jan 2018 18:36:42 +0000 (20:36 +0200)]
drm/i915: Assert that we don't overflow frontbuffer tracking bits
Add some compile time assrts to the frontbuffer tracking to make sure
that we have enough bits per pipe to cover all the planes, and that we
have enough total bits to cover all the planes across all pipes.
We'll ignore any potential clash between the overlay bit and the
plane bits because that will allow us to keep using a total of 32
bits for the foreseeable future.
While at it change the macros to use BIT() and GENMASK(). The latter
gets rid of the hardcoded 0xff and thus means we can change the
number of bits per pipe by just changing
INTEL_FRONTBUFFER_BITS_PER_PIPE.
Chris Wilson [Mon, 19 Feb 2018 22:06:31 +0000 (22:06 +0000)]
drm/i915: Track number of pending freed objects
During igt, we frequently call into the driver to reset both HW and
driver state (idling the device, waiting for it to become idle and
freeing off old objects) to ensure that we start each test/subtest/pass
from known state. This process incurs an RCU barrier or two to ensure
that any such pending frees are indeed flushed before we return.
However, unconditionally waiting on the RCU barrier adds needless delay
to many callers, which adds up to several seconds when repeated thousands
of times. We can skip the rcu_barrier() if by tracking how many outstanding
frees we have, we know there are none.
The same path is used along suspend, where we may be able to save the
unconditional RCU barrier.
To put it into perspective with a completely meaningless
microbenchmark, igt/gem_sync/idle is improved from 50ms to 30us on bdw.
v2: Remove the extra synchronize_rcu() inside i915_drop_caches_set()
Chris Wilson [Wed, 15 Nov 2017 10:50:35 +0000 (10:50 +0000)]
drm/i915/: Initialise trans_min for skl_compute_transition_wm()
clang spots
drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (INTEL_GEN(dev_priv) >= 10)
but fortunately for us we skip the function unless on a gen10+ device.
However, to keep the function generic in case we do want to re-enable it
for gen9 again, initialise trans_min to 0.
References: ca47667f523e ("drm/i915/gen10: Calculate and enable transition WM") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115105036.1094-3-chris@chris-wilson.co.uk Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Mon, 19 Feb 2018 14:01:44 +0000 (14:01 +0000)]
drm/i915: Clear the in-use marker on execbuf failure
If we fail to unbind the vma (due to a signal on an active buffer that
needs to be moved for the next execbuf), then we need to clear the
persistent tracking state we setup for this execbuf.
Fixes: c7c6e46f913b ("drm/i915: Convert execbuf to use struct-of-array packing for critical fields")
Testcase: igt/gem_fenced_exec_thrash/no-spare-fences-busy* Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.14+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219140144.24004-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 19 Feb 2018 10:09:26 +0000 (10:09 +0000)]
drm/i915: Prune gen8_gt_irq_handler
The compiler is not automatically caching the i915->regs address inside
a register and emitting a load for every mmio access. For simple
functions like gen8_gt_irq_handler that are already using the raw
accessors, we can open-code them for substantial savings:
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-83 (-83)
Function old new delta
gen8_gt_irq_handler 290 266 -24
gen8_gt_irq_ack 181 122 -59
Total: Before=954637, After=954554, chg -0.01%
Chris Wilson [Thu, 15 Feb 2018 07:37:12 +0000 (07:37 +0000)]
drm/i915: Track GT interrupt handling using the master iir
Keep the master iir and use it to reduce the number of reads and writes
to the GT iir array, i.e. only the bits marked as set by the master iir
are valid inside GT iir array and will be handled during the interrupt.
Chris Wilson [Mon, 19 Feb 2018 12:50:46 +0000 (12:50 +0000)]
drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use
As the driver is called to handle circumstances beyond it's control, we
cannot assume that the pm_runtime core is happy to see us. For example,
if we are called from shrink_slab to free up our pages during suspend,
rpm may be disabled and pm_runtime_if_in_use() decides to fail with
-EINVAL rather than simply say no. This is expected to happen, so don't
warn. For example,
drm: intel_dpio_phy: fix kernel-doc comments at nested struct
The in-lined comments for channel.port doesn't follow the syntax
described at kernel-doc document, causing the following warning:
$ ./scripts/kernel-doc -none drivers/gpu/drm/i915/intel_dpio_phy.c
drivers/gpu/drm/i915/intel_dpio_phy.c:154: warning: Function parameter or member 'channel.port' not described in 'bxt_ddi_phy_info'
While the best would be for the Kernel to deduce that from the
context, supporting it is not trivial. So, let's just stick with
the existing syntax.
[Jani: depends on "scripts: kernel-doc: support in-line comments on
nested structs/unions" to actually fix the warning.]
drm/i915: Release connector iterator on a digital port conflict.
Hitting the failure path through check_digital_port_conflicts triggers:
================================================
WARNING: lock held when returning to user space!
4.16.0-rc1-CI-kasan_1+ #1 Tainted: G W
------------------------------------------------
kms_3d/1439 is leaving the kernel with locks still held!
1 lock held by kms_3d/1439:
#0: (drm_connector_list_iter){.+.+}, at: [<000000003745d183>] intel_atomic_check+0x1d9d/0x3ff0 [i915]
Rearrange the code to have a single exit path through the unlock.
Chris Wilson [Fri, 16 Feb 2018 15:32:10 +0000 (15:32 +0000)]
drm/i915/execlists: Remove too early assert
We can't assert that the execlists are active before we set the flag. So
perform the assert after we are expected to have marked the execlists
active.
Fixes: 339ccd35b42c ("drm/i915: Assert that we always complete a submission to guc/execlists") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180216153210.30551-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 15 Feb 2018 16:25:53 +0000 (16:25 +0000)]
drm/i915: Assert that we always complete a submission to guc/execlists
The continual resubmission model for execlists (and emulated over guc)
requires that we keep feeding requests into the HW in order to generate
more CS interrupts to drain the rest of the queue. Add a couple of
asserts to ensure that we don't skip a cycle and come to a grinding
halt.
Christian König [Fri, 16 Feb 2018 12:43:38 +0000 (13:43 +0100)]
drm: move read_domains and write_domain into i915
i915 is the only driver using those fields in the drm_gem_object
structure, so they only waste memory for all other drivers.
Move the fields into drm_i915_gem_object instead and patch the i915 code
with the following sed commands:
sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c
sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c
Mahesh Kumar [Thu, 15 Feb 2018 09:56:41 +0000 (15:26 +0530)]
drm/i915/cnl: Fix PORT_TX_DW5/7 register address
Register Address for CNL_PORT_DW5_LN0_D is 0x162E54, but current code is
defining it as 0x162ED4. Similarly for CNL_PORT_DW7_LN0_D register address
is defined 0x162EDC instead of 0x162E5C, fix it.
The frame counter may have got reset between disabling and enabling vblank
interrupts due to DMC putting the hardware to DC5/6 states if PSR was
active. The frame counter could also have stalled if PSR was active in case
there was no DMC. The frame counter resetting has a user visible impact
of screen freezes.
Make use of drm_vblank_restore() to compute missed vblanks for the duration
in which vblank interrupts were disabled and update the vblank counter with
this value as diff. There's no need to check if PSR was actually active in
the interrupt disabled duration, so simplify the check to a feature check.
Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it
from going back again as long as the there are pending interrupts. So, we
don't have to explicity disallow DC5/6 after enabling vblank interrupts to
keep the counter running.
This change is not applicable to CHV, as enabling interrupts does not
prevent the hardware from activating PSR.
v2: Added comments(Rodrigo) and rewrote commit message.
drm/vblank: Restoring vblank counts after device PM events.
The HW frame counter can get reset if device enters a low power state after
vblank interrupts were disabled. This messes up any following vblank count
update as a negative diff (huge unsigned diff) is calculated from the HW
frame counter change. We cannot ignore negative diffs altogther as there
could be legitimate wrap arounds. So, allow drivers to update vblank->count
with missed vblanks for the time interrupts were disabled. This is similar
to _crtc_vblank_on() except that vblanks interrupts are not enabled at the
end as this function is expected to be called from the driver
_enable_vblank() vfunc.
v2: drm_crtc_vblank_restore should take crtc as arg. (Chris)
Add docs and sprinkle some asserts.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-9-dhinakaran.pandiyan@intel.com
drm/vblank: Do not update vblank count if interrupts are already disabled.
Updating vblank counts requires register reads and these reads may not
return meaningful values if the device was in a low power state after
vblank interrupts were last disabled. So, update the count only if vblank
interrupts are enabled. Secondly, this means the registers should be read
before disabling vblank interrupts.
drm/atomic: Handle 64-bit return from drm_crtc_vblank_count()
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64.
The flip ioctl receives a 32-bit target sequence from user space and is
compared against the current sequence from drm_crtc_vblank_count(). So,
typecast return from drm_crtc_vblank_count() explicitly to add clarity.
__drm_crtcs_state.last_vblank_count however only ever stores the value from
drm_crtc_vblank_count() and can be upgraded to u64.
drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this
down to u32 either fixes a potential problem or serves to add clarity in
case the implicit typecasting was already correct.
drm/radeon: Handle 64-bit return from drm_crtc_vblank_count()
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes a potential problem or serves to add clarity in case
the implicit typecasting was already correct.
Cc: Keith Packard <keithp@keithp.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Keith Packard <keithp@keithp.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-5-dhinakaran.pandiyan@intel.com
drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes a potential problem or serves to add clarity in case
the typecasting was implicitly done.
Cc: Keith Packard <keithp@keithp.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> for both this patch Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-4-dhinakaran.pandiyan@intel.com
drm/i915: Handle 64-bit return from drm_crtc_vblank_count()
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64, store all the bits
without truncating. There is no need to type cast this value down to
32-bits.
Cc: Keith Packard <keithp@keithp.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-3-dhinakaran.pandiyan@intel.com
drm/vblank: Data type fixes for 64-bit vblank sequences.
drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is >= 2^32) as reference, the requested sequence remains a 32-bit
value and gets queued like that. However, the code that checks if the
requested sequence has passed compares this against the 64-bit vblank
count.
With drm_vblank_count() returning all bits of the vblank count, update
drm_crtc_accurate_vblank_count() so that drm_crtc_arm_vblank_event() queues
the correct sequence. Otherwise, this leads to prolonged waits for a vblank
sequence when the current count is >=2^32.
drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR
Fix inconsistent IS_ERR and PTR_ERR in shrink_boom.
The proper pointer to use is _explode_ instead of _purge_.
This issue was detected with the help of Coccinelle.
Fixes: fe215c8bc426 ("drm/i915/selftests: add missing gtt shrinker test") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214211234.GA22341@embeddedgus Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Thu, 15 Feb 2018 11:07:59 +0000 (11:07 +0000)]
drm/i915/gtt: Convert WARN_ON to GEM debugging
As we presume that we have sufficient coverage of CI for new machines
and new code paths, we do not need to have user impacting WARN_ON for
programming errors inside i915_gem_gtt.c, so convert those over to
GEM_BUG_ON. This leaves the memory debugging WARN_ON in place as they
are not so easy to exercise with CI.
Chris Wilson [Wed, 14 Feb 2018 16:07:20 +0000 (16:07 +0000)]
drm/i915: Clean up ancient doc comments for i915_ioc32.c
As befitting a file dedicated to the mistakes of the past,
drivers/gpu/drm/i915/i915_ioc32.c:2: warning: Cannot understand * \file i915_ioc32.c
on line 2 - I thought it was a doc line
drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'filp' not described in 'i915_compat_ioctl'
drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'cmd' not described in 'i915_compat_ioctl'
drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'arg' not described in 'i915_compat_ioctl'
Rodrigo Vivi [Wed, 14 Feb 2018 20:42:05 +0000 (12:42 -0800)]
drm/i915/cnl: Remove alpha_support protection
We now have a stable cnl on our CI and it seems mostly
green without big risks of blank screen or anything
blowing up on linux installations in the future.
As a reminder i915.alpha_support was created to protect
future linux installation's iso images that might contain a
kernel from the enabling time of the new platform. Without this
protection most of linux installation was recommending
nomodeset option during installation that was getting stick
there after installation.
Specifically, alpha support says nothing about the development
state of the hardware, and everything about the state of the
driver in a kernel release.
This is semantically no different from the old
preliminary_hw_support flag, but the old one was all too often
interpreted as (preliminary hw) support instead of the intended
(preliminary) hw support, and it was misleading for everyone.
Hence the rename.
v2: Fix the typos and include more history about the parameter
rename on commit message. (Jani)
Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-cnl-y3.html Cc: James Ausmus <james.ausmus@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214204205.4446-1-rodrigo.vivi@intel.com
Rodrigo Vivi [Thu, 8 Feb 2018 07:32:19 +0000 (23:32 -0800)]
drm/i915/cnl: Sync PCI ID with Spec.
Add one missing PCI ID and sort them in a way
that gets easier to review and compare against spec's
table.
When trying to sync libdrm and mesa id list with kernel
and spec I noticed something was wrong and we were missing
a pci id. So to make our lives easier when checking against
spec let's simplify and sort like spec does.
drm/i915: Fix rsvd2 mask when out-fence is returned
GENMASK_ULL wants the high bit of the mask first. The current value
cancels the in-fence when an out-fence is returned.
Fixes: fec0445caa273 ("drm/i915: Support explicit fencing for execbuf")
Testcase: igt/gem_exec_fence/keep-in-fence* Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180214191827.8465-1-daniele.ceraolospurio@intel.com Cc: <stable@vger.kernel.org> # v4.12+
Chris Wilson [Wed, 14 Feb 2018 14:03:03 +0000 (14:03 +0000)]
drm/i915: Fixup kerneldoc for intel_pm.c
drivers/gpu/drm/i915/intel_pm.c:750: warning: Function parameter or member 'fifo_size' not described in 'intel_calculate_wm'
drivers/gpu/drm/i915/intel_pm.c:5900: warning: Function parameter or member 'crtc' not described in 'intel_update_watermarks'
Chris Wilson [Wed, 14 Feb 2018 13:49:22 +0000 (13:49 +0000)]
drm/i915: Fixup kerneldoc
drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'dev_priv' not described in 'intel_PLL_is_valid'
drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'limit' not described in 'intel_PLL_is_valid'
drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'clock' not described in 'intel_PLL_is_valid'
drivers/gpu/drm/i915/intel_display.c:4769: warning: Function parameter or member 'crtc_state' not described in 'skl_update_scaler_plane'
drivers/gpu/drm/i915/intel_display.c:4769: warning: Excess function parameter 'state' description in 'skl_update_scaler_plane'
drivers/gpu/drm/i915/intel_display.c:4967: warning: Function parameter or member 'new_crtc_state' not described in 'intel_post_enable_primary'
drivers/gpu/drm/i915/intel_display.c:12650: warning: Function parameter or member 'new_state' not described in 'intel_prepare_plane_fb'
drivers/gpu/drm/i915/intel_display.c:12650: warning: Excess function parameter 'fb' description in 'intel_prepare_plane_fb'
drivers/gpu/drm/i915/intel_display.c:12763: warning: Function parameter or member 'old_state' not described in 'intel_cleanup_plane_fb'
drivers/gpu/drm/i915/intel_display.c:12763: warning: Excess function parameter 'fb' description in 'intel_cleanup_plane_fb'
Chris Wilson [Wed, 14 Feb 2018 13:49:21 +0000 (13:49 +0000)]
drm/i915/atomic: Fixup kerneldoc
drivers/gpu/drm/i915/intel_atomic.c:198: warning: Function parameter or member 'state' not described in 'intel_crtc_destroy_state'
drivers/gpu/drm/i915/intel_atomic.c:222: warning: Function parameter or member 'intel_crtc' not described in 'intel_atomic_setup_scalers'
drivers/gpu/drm/i915/intel_atomic.c:222: warning: Excess function parameter 'crtc' description in 'intel_atomic_setup_scalers'
Chris Wilson [Wed, 14 Feb 2018 10:53:32 +0000 (10:53 +0000)]
drm/i915: Fixup kerneldoc for intel_uc_fw_upload()
Just a parameter name change that was lost to kerneldoc.
drivers/gpu/drm/i915/intel_uc_fw.c:209: warning: Function parameter or member 'xfer' not described in 'intel_uc_fw_upload'
drivers/gpu/drm/i915/intel_uc_fw.c:209: warning: Excess function parameter 'loader' description in 'intel_uc_fw_upload'
Chris Wilson [Wed, 14 Feb 2018 10:40:40 +0000 (10:40 +0000)]
drm/i915: Add missing kerneldoc parameters for huc_ucode_xfer
During the recent upheaval to uc, the parameters to huc_ucode_xfer
were changed, but the kerneldoc left behind.
drivers/gpu/drm/i915/intel_huc.c:128: warning: Function parameter or member 'huc_fw' not described in 'huc_ucode_xfer'
drivers/gpu/drm/i915/intel_huc.c:128: warning: Function parameter or member 'vma' not described in 'huc_ucode_xfer'
drivers/gpu/drm/i915/intel_huc.c:128: warning: Excess function parameter 'dev_priv' description in 'huc_ucode_xfer'
Chris Wilson [Wed, 14 Feb 2018 09:29:09 +0000 (09:29 +0000)]
drm/i915/lvds: Fixup commentary
Remove the kerneldoc markup applied to non-kerneldoc comments and
convert the multiline comments to the canonical style.
drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'encoder' not described in 'intel_enable_lvds'
drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'pipe_config' not described in 'intel_enable_lvds'
drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'conn_state' not described in 'intel_enable_lvds'
drivers/gpu/drm/i915/intel_lvds.c:453: warning: Function parameter or member 'connector' not described in 'intel_lvds_detect'
drivers/gpu/drm/i915/intel_lvds.c:453: warning: Function parameter or member 'force' not described in 'intel_lvds_detect'
drivers/gpu/drm/i915/intel_lvds.c:471: warning: Function parameter or member 'connector' not described in 'intel_lvds_get_modes'
drivers/gpu/drm/i915/intel_lvds.c:932: warning: Function parameter or member 'dev_priv' not described in 'intel_lvds_init'
drivers/gpu/drm/i915/intel_lvds.c:932: warning: Excess function parameter 'dev' description in 'intel_lvds_init'
Chris Wilson [Wed, 14 Feb 2018 09:29:08 +0000 (09:29 +0000)]
drm/i915/dvo: Fixup commentary
Remove the kerneldoc markup applied to non-kerneldoc comments and
convert the multiline comments to the canonical style.
drivers/gpu/drm/i915/intel_dvo.c:303: warning: Function parameter or member 'connector' not described in 'intel_dvo_detect'
drivers/gpu/drm/i915/intel_dvo.c:303: warning: Function parameter or member 'force' not described in 'intel_dvo_detect'
drivers/gpu/drm/i915/intel_dvo.c:382: warning: Function parameter or member 'encoder' not described in 'intel_dvo_get_current_mode'
Chris Wilson [Wed, 14 Feb 2018 09:29:07 +0000 (09:29 +0000)]
drm/i915/dvo: Remove incorrect kerneldoc markups
Regular comments where being marked up for kerneldoc, but were not
formatted properly. Remove the markup to remove the warnings.
drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'dvo' not described in 'ivch_read'
drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'addr' not described in 'ivch_read'
drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'data' not described in 'ivch_read'
Chris Wilson [Wed, 14 Feb 2018 09:17:47 +0000 (09:17 +0000)]
drm/i915/panel: Split range scaling calculation for readiblity
Split the 64b multiplication from the division so that it doesn't sprawl
across a couple of lines and use mul_u32_u32() instead of open-coding
the 64b conversion.
Chris Wilson [Wed, 14 Feb 2018 09:17:46 +0000 (09:17 +0000)]
drm/i915/panel: Add missing parameters to kerneldoc
drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'source_min' not described in 'scale'
drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'source_max' not described in 'scale'
drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'target_min' not described in 'scale'
drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'target_max' not described in 'scale'
Chris Wilson [Wed, 14 Feb 2018 09:09:05 +0000 (09:09 +0000)]
drm/i915/sdvo: Tidy up commentary
Drop the kerneldoc markup from the non-kerneldoc comments and convert
the multi-line comments to the canonical format.
drivers/gpu/drm/i915/intel_sdvo.c:223: warning: Function parameter or member 'intel_sdvo' not described in 'intel_sdvo_write_sdvox'
drivers/gpu/drm/i915/intel_sdvo.c:223: warning: Function parameter or member 'val' not described in 'intel_sdvo_write_sdvox'
drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'intel_sdvo' not described in 'intel_sdvo_get_trained_inputs'
drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'input_1' not described in 'intel_sdvo_get_trained_inputs'
drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'input_2' not described in 'intel_sdvo_get_trained_inputs'
drivers/gpu/drm/i915/intel_sdvo.c:2311: warning: Function parameter or member 'dev_priv' not described in 'intel_sdvo_select_ddc_bus'
drivers/gpu/drm/i915/intel_sdvo.c:2311: warning: Function parameter or member 'sdvo' not described in 'intel_sdvo_select_ddc_bus'
Chris Wilson [Wed, 14 Feb 2018 08:58:14 +0000 (08:58 +0000)]
drm/i915/tv: Cleanup up obsolete comments
The ages old kerneldoc-esque comments still refer to the original stubs
and not the more complete functions. As they were only describing the
external entry points (or at least thought themselves to be, they had
drifted!), they don't provide any commentary for the code flow.
drivers/gpu/drm/i915/intel_tv.c:379: warning: cannot understand function prototype: 'const struct tv_mode tv_modes[] = '
drivers/gpu/drm/i915/intel_tv.c:1133: warning: bad line:
drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'intel_tv' not described in 'intel_tv_detect_type'
drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'connector' not described in 'intel_tv_detect_type'
drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'connector' not described in 'intel_tv_detect'
drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'ctx' not described in 'intel_tv_detect'
drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'force' not described in 'intel_tv_detect'
drivers/gpu/drm/i915/intel_tv.c:1351: warning: Function parameter or member 'connector' not described in 'intel_tv_get_modes'
projects / mirror_ubuntu-hirsute-kernel.git / log