The merge is clean, but the arm build fails afterwards,
due to API changes in the regulator tree.
I've included the patch into the merge to fix the build.
Signed-off-by: Dave Airlie <airlied@redhat.com>
devicetree changes queued up for v4.1. Here are the highlights:
- Lots of unittest cleanup from Frank Rowand
- Bugfixes and updates to the of_graph code
- Tighten up of_get_mac_address() code
- Documentation updates
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVMYiQAAoJEMWQL496c2LNyrcP/2acOKeyHk7zBVWxaYe6nO52
iwpDb+UDEdW+1Cx5e+OpF1gqoY7lJ2Q+Uvm65+z00a46Fnl0cWuSYFIV7e0wjE5/
3EAB4cQgiCzToDnbtCu4U6XlpNlQz/q85tV9X/EpYApHNb+BKN6RMzyIDm48lzJY
L6SG4fxFJVpeDxweZFGaWE9/Ildr4vOS+4GZpE0Az3iX2WDrQPioKjuOw8TeUHRO
xwvfv1TpyQFa2qHZLI4AmZSN8VJBw82OuAyZHAGsE4bekfafeqVFt0ZtYYoiAbIM
rw+dUCnWARc7gm8z2PaYnZGs8O++Flb03clDeFrdrvfZIewXWEkZ1TxrKIb9bLyP
A8tlSnbnCdXYSzyaFYH2TgUtc7gQosssfImuJjUq1qQkeEitLP6VzEsekN1h6sx7
axFiBdiCXPvn8ti+AlK9tYfSM0ZhAzvfpuLM0hpTAk3De3NfbJQiyp6eyXAInLne
cs9RGPXNPuKX0tISZ29vA8tmOSrDInfeEEW/Lqu4l+HedcLssWjReY0xVsZS3pbi
xGiD5/Ztdha9keTIQdW+7R0SE1YsZTpwZbQt0HeHcE+pzFPF/3TLIIIYhYRVSPsm
D+g5W+bVxht8NC380UEC8vpAyP1CYSnq/aVrDfJiXZVOS7b/dyZDk6Y6LSBOm9Em
9qLaPASncxVinaNcGlyj
=u6Zy
-----END PGP SIGNATURE-----
Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux
Pull devicetree changes from Grant Likely:
"Here are the devicetree changes queued up for v4.1. Nothing really
exciting here. Rob has another few commits for big-endian attached
UARTs, but those will be sent in a separate merge request since they
haven't been as thoroughly tested as this batch.
Here are the highlights:
- lots of unittest cleanup from Frank Rowand
- bugfixes and updates to the of_graph code
- tighten up of_get_mac_address() code
- documentation updates"
* tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux:
of/unittest: Fix of_platform_depopulate test case
of/unittest: early return from test skips tests
of/unittest: breadcrumbs to reduce pain of future maintainers
of/unittest: reduce checkpatch noise - line after declarations
of/unittest: typo in error string
of/unittest: add const where needed
of_net: factor out repetitive code from of_get_mac_address()
drivers/of: Add empty ranges quirk for PA-Semi
of: Allow selection of OF_DYNAMIC and OF_OVERLAY if OF_UNITTEST
of: Empty node & property flag accessors when !OF
of: Explicitly include linux/types.h in of_graph.h
dt-bindings: brcm: rationalize Broadcom documentation naming
of/unittest: replace 'selftest' with 'unittest'
Documentation: rename of_selftest.txt to of_unittest.txt
Documentation: update the of_selftest.txt
dt: OF_UNITTEST make dependency broken
MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
of: Add of_graph_get_port_by_id function
of: Add for_each_endpoint_of_node helper macro
of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
We have grown a number of different implementations of
DIV_ROUND_CLOSEST_ULL throughout the kernel. Move the i915 one to
kernel.h so that it can be reused.
Signed-off-by: Javi Merino <javi.merino@arm.com>
Reviewed-by: Jeff Epler <jepler@unpythonic.net>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Guenter Roeck <linux@roeck-us.net>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Alex Elder <elder@linaro.org>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Misc i915 fixes.
* tag 'drm-intel-next-fixes-2015-04-15' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Dont enable CS_PARSER_ERROR interrupts at all
drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover
drm/i915: Allocate connector state together with the connectors
drm/i915/chv: Remove DPIO force latency causing interpair skew issue
drm/i915: Don't cancel DRRS worker synchronously for flush/invalidate
drm/i915: Fix locking in DRRS flush/invalidate hooks
One more drm-misch pull for 4.1 with mostly simple stuff and boring
refactoring. Even the cursor fix from Matt is just to make a really anal
igt happy.
* tag 'topic/drm-misc-2015-04-15' of git://anongit.freedesktop.org/drm-intel:
drm: fix trivial typo mistake
drm: Make integer overflow checking cover universal cursor updates (v2)
drm: make crtc/encoder/connector/plane helper_private a const pointer
drm/armada: constify struct drm_encoder_helper_funcs pointer
drm/radeon: constify more struct drm_*_helper funcs pointers
drm/edid: add #defines for ELD versions
drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros
drm: Use kref_put_mutex in drm_gem_object_unreference_unlocked
drm/drm: constify all struct drm_*_helper funcs pointers
drm/qxl: constify all struct drm_*_helper funcs pointers
drm/nouveau: constify all struct drm_*_helper funcs pointers
drm/radeon: constify all struct drm_*_helper funcs pointers
drm/gma500: constify all struct drm_*_helper funcs pointers
drm/mgag200: constify all struct drm_*_helper funcs pointers
drm/exynos: constify all struct drm_*_helper funcs pointers
drm: Fix some typos
This set of patches adjust the setup of the HDMI CTS/N values for audio
support to be compliant with the work-around given in the iMX6 errata
documentation as part of the preparation for integrating audio support
for this driver, and also update the HDMI phy configuration for Rockchip
devices to improve the HDMI eye pattern.
* 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm: rockchip/dw_hdmi-rockchip: improve for HDMI electrical test
drm: bridge/dw_hdmi: separate VLEVCTRL settting into platform driver
drm: bridge/dw_hdmi: fixed codec style
drm: bridge/dw_hdmi: adjust n/cts setting order
drm: bridge/dw_hdmi: protect n/cts setting with a mutex
drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()
Conflicts:
drivers/gpu/drm/imx/dw_hdmi-imx.c
Some final bits for 4.1. Some fixes for userptrs and allow a new
packet for VCE to enable some new features in mesa.
* 'drm-next-4.1' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: allow creating overlapping userptrs
drm/radeon: add userptr config option
drm/radeon: add video usability info support for VCE
of the TRACE_DEFINE_ENUM() macro that can be used by tracepoints.
Tracepoints have helper functions for the TP_printk() called
__print_symbolic() and __print_flags() that lets a numeric number be
displayed as a a human comprehensible text. What is placed in the
TP_printk() is also shown in the tracepoint format file such that
user space tools like perf and trace-cmd can parse the binary data
and express the values too. Unfortunately, the way the TRACE_EVENT()
macro works, anything placed in the TP_printk() will be shown pretty
much exactly as is. The problem arises when enums are used. That's
because unlike macros, enums will not be changed into their values
by the C pre-processor. Thus, the enum string is exported to the
format file, and this makes it useless for user space tools.
The TRACE_DEFINE_ENUM() solves this by converting the enum strings
in the TP_printk() format into their number, and that is what is
shown to user space. For example, the tracepoint tlb_flush currently
has this in its format file:
__print_symbolic(REC->reason,
{ TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" },
{ TLB_REMOTE_SHOOTDOWN, "remote shootdown" },
{ TLB_LOCAL_SHOOTDOWN, "local shootdown" },
{ TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" })
After adding:
TRACE_DEFINE_ENUM(TLB_FLUSH_ON_TASK_SWITCH);
TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN);
TRACE_DEFINE_ENUM(TLB_LOCAL_SHOOTDOWN);
TRACE_DEFINE_ENUM(TLB_LOCAL_MM_SHOOTDOWN);
Its format file will contain this:
__print_symbolic(REC->reason,
{ 0, "flush on task switch" },
{ 1, "remote shootdown" },
{ 2, "local shootdown" },
{ 3, "local mm shootdown" })
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVLBTuAAoJEEjnJuOKh9ldjHMIALdRS755TXCZGOf0r7O2akOR
wMPeum7C+ae1mH+jCsJKUC0/jUfQKaMt/UxoHlipDgcGg8kD2jtGnGCw4Xlwvdsr
y4rFmcTRSl1mo0zDSsg6ujoupHlVYN0+JPjrd7S3cv/llJoY49zcanNLF7S2XLeM
dZCtWRLWYpBiWO68ai6AqJTnE/eGFIqBI048qb5Eg8dbK243SSeSIf9Ywhb+VsA+
aq6F7cWI/H6j4tbeza8tAN19dcwenDro5EfCDY8ARQHJu1f6Y3+DLf2imjkd6Aiu
JVAoGIjHIpI+djwCZC1u4gi4urjfOqYartrM3Q54tb3YWYqHeNqP2ASI2a4EpYk=
=Ixwt
-----END PGP SIGNATURE-----
Merge tag 'trace-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing updates from Steven Rostedt:
"Some clean ups and small fixes, but the biggest change is the addition
of the TRACE_DEFINE_ENUM() macro that can be used by tracepoints.
Tracepoints have helper functions for the TP_printk() called
__print_symbolic() and __print_flags() that lets a numeric number be
displayed as a a human comprehensible text. What is placed in the
TP_printk() is also shown in the tracepoint format file such that user
space tools like perf and trace-cmd can parse the binary data and
express the values too. Unfortunately, the way the TRACE_EVENT()
macro works, anything placed in the TP_printk() will be shown pretty
much exactly as is. The problem arises when enums are used. That's
because unlike macros, enums will not be changed into their values by
the C pre-processor. Thus, the enum string is exported to the format
file, and this makes it useless for user space tools.
The TRACE_DEFINE_ENUM() solves this by converting the enum strings in
the TP_printk() format into their number, and that is what is shown to
user space. For example, the tracepoint tlb_flush currently has this
in its format file:
__print_symbolic(REC->reason,
{ TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" },
{ TLB_REMOTE_SHOOTDOWN, "remote shootdown" },
{ TLB_LOCAL_SHOOTDOWN, "local shootdown" },
{ TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" })
After adding:
TRACE_DEFINE_ENUM(TLB_FLUSH_ON_TASK_SWITCH);
TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN);
TRACE_DEFINE_ENUM(TLB_LOCAL_SHOOTDOWN);
TRACE_DEFINE_ENUM(TLB_LOCAL_MM_SHOOTDOWN);
Its format file will contain this:
__print_symbolic(REC->reason,
{ 0, "flush on task switch" },
{ 1, "remote shootdown" },
{ 2, "local shootdown" },
{ 3, "local mm shootdown" })"
* tag 'trace-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: (27 commits)
tracing: Add enum_map file to show enums that have been mapped
writeback: Export enums used by tracepoint to user space
v4l: Export enums used by tracepoints to user space
SUNRPC: Export enums in tracepoints to user space
mm: tracing: Export enums in tracepoints to user space
irq/tracing: Export enums in tracepoints to user space
f2fs: Export the enums in the tracepoints to userspace
net/9p/tracing: Export enums in tracepoints to userspace
x86/tlb/trace: Export enums in used by tlb_flush tracepoint
tracing/samples: Update the trace-event-sample.h with TRACE_DEFINE_ENUM()
tracing: Allow for modules to convert their enums to values
tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values
tracing: Update trace-event-sample with TRACE_SYSTEM_VAR documentation
tracing: Give system name a pointer
brcmsmac: Move each system tracepoints to their own header
iwlwifi: Move each system tracepoints to their own header
mac80211: Move message tracepoints to their own header
tracing: Add TRACE_SYSTEM_VAR to xhci-hcd
tracing: Add TRACE_SYSTEM_VAR to kvm-s390
tracing: Add TRACE_SYSTEM_VAR to intel-sst
...
We stopped handling them in
commit aaecdf611a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Nov 4 15:52:22 2014 +0100
drm/i915: Stop gathering error states for CS error interrupts
but just clearing is apparently not enough: A sufficiently dead gpu
left behind by firmware (*cough* coreboot *cough*) can keep the gpu in
an endless loop of such interrupts, eventually leading to the nmi
firing. And definitely to what looks like a machine hang.
Since we don't even enable these interrupts on gen5+ let's do the same
on earlier platforms.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171
Tested-by: Mono <mono-for-kernel-org@donderklumpen.de>
Tested-by: info@gluglug.org.uk
Cc: stable@vger.kernel.org
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must be held without that lock.
This is a simplified version of the identically named patch by Chris Wilson.
Regression from commit ab8d66752a
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Mon Feb 2 15:44:15 2015 +0000
drm/i915: Track old framebuffer instead of object
v2: Bikeshedding.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89166
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Our legacy SetPlane updates perform integer overflow checking on a
plane's destination rectangle in drm_mode_setplane(), and atomic updates
handled as part of a drm_atomic_state transaction do the same checking
in drm_atomic_plane_check(). However legacy cursor updates that get
routed through universal plane interfaces may bypass this overflow
checking if the driver's .update_plane is serviced by the transitional
plane helpers rather than the full atomic plane helpers.
Move the check for destination rectangle integer overflow from the
drm_mode_setplane() to __setplane_internal() so that it also covers
cursor operations.
This fixes an issue first noticed with i915 commit:
commit ff42e093e9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Mar 2 16:35:20 2015 +0100
Revert "drm/i915: Switch planes from transitional helpers to full
atomic helpers"
The above revert switched us from full atomic helpers back to the
transitional helpers, and in doing so we lost the overflow checking here
for universal cursor updates. Even though such extreme cursor positions
are unlikely to actually happen in the wild, we still don't want there
to be a change of behavior when drivers switch from transitional helpers
to full helpers.
v2: Move check from setplane ioctl to setplane_internal rather than
adding an additional copy of the checks to the transitional plane
helpers. (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Testcase: igt/kms_cursor_crc
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84269
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
nvbios_extend() returns 1 to indicate "extended the array" and 0 to
indicate the array is already big enough. This is used by the core
shadowing code to prevent re-fetching chunks of the image that have
already been shadowed.
The ACPI fetching code may possibly need to extend this further due
to requiring fetches to happen in 4KiB chunks.
Under certain circumstances (that happen if the total image size is
a multiple of 4KiB), the memory allocated to store the shadow will
already be big enough, causing the ACPI code's nvbios_extend() call
to return 0, which is misinterpreted as a failure.
The fix is simple, accept >= 0 as a successful condition here. The
core will have already made sure that we're not re-fetching data we
already have.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89047
v2 (Ben Skeggs):
- dropped hunk which would cause unnecessary re-fetching
- more descriptive explanation
Signed-off-by: Jan Vesely <jano.vesely@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Uncertain whether the GPC pack change is due to a newer driver version,
or a legitimate difference from GM204. My GM204 has broken vram, so
can't currently try a newer binary driver on it to confirm.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Under certain circumstances the trapped address will contain subc 7,
which GK104 GR doesn't have anymore.
Notice this case to avoid causing additional priv ring faults.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
No idea if "3" is a constant or derived from something else, but the
value is unchanged in the limited traces of gm107/gm204 I have here.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Make static a few functions and structures that should be.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A "return 0" found its way in the middle of the error path of
nouveau_platform_probe(), remove it as it will make the kernel crash if
we try to unload the module afterwards.
While we are at it, also remove the IOMMU domain if it has been created,
as we should.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvkm_mm_fini() was not called when exiting the driver, resulting in a
memory leak. Fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On some of these chipsets, reading NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK
can trigger a PRI fault and return an error code instead of a TPC mask,
unless PGOB has been disabled first.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Before we moved gk110's implementation of this to pmu, the functions were
identical. This commit just switches GK208 to use the new (more complete)
implementation of the power-up sequence.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Turns out the PTHERM part of this dance is bracketed by the same PMU
fiddling that occurs on GK104/6, let's assume it's also PGOB.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If a memory allocation fails when using the DMA allocator,
gk20a_instobj_dtor_dma() will be called on the failed instmem object.
At this time, node->handle might not be NULL despite the call to
dma_alloc_attrs() having failed. node->cpuaddr is the right member to
check for such a failure, so use it instead.
Reported-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
User-space use mappable BOs notably for fences, and expects that a
value update by the GPU will be immediatly visible through the
user-space mapping.
ARM has a property that may prevent this from happening though: memory
can be mapped multiple times only if the different mappings share the
same caching properties. However all the lowmem memory is already
identity-mapped into the kernel with cache enabled, so when user-space
requests an uncached mapping, we actually get an "undefined caching
policy" one and this has strange side-effects described on Freedesktop
bug 86690.
To prevent this from happening, allow user-space to explicitly specify
which objects should be coherent, and create such objects with the
TTM_PL_FLAG_UNCACHED flag. This will make TTM allocate memory using the
DMA API, which will fix the identify mapping and allow us to safely map
the objects to user-space uncached.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Let GK20A's instmem take advantage of the IOMMU if it is present. Having
an IOMMU means that instmem is no longer allocated using the DMA API,
but instead obtained through page_alloc and made contiguous to the GPU
by IOMMU mappings.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tegra SoCs have an IOMMU that can be used to present non-contiguous
physical memory as contiguous to the GPU and maximize the use of large
pages in the GPU MMU, leading to performance gains. This patch adds
support for probing such a IOMMU if present and make its properties
available in the nouveau_platform_gpu structure so subsystems can take
advantage of it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
instmem for GK20A is allocated using dma_alloc_coherent(), which
provides us with a coherent CPU mapping that we never use because
instmem objects are accessed through PRAMIN. Switch to
dma_alloc_attrs() which gives us the option to dismiss that CPU mapping
and free up some CPU virtual space.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Now that Nouveau can operate even when there is no RAM device, remove
the dummy one used by GK20A.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GK20A does not have dedicated RAM, thus having a RAM device for it does
not make sense. Move the contiguous physical memory allocation to
instmem.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Having a RAM device does not make sense for chips like GK20A which have
no dedicated video memory. The dummy RAM device that we used so far
works as a temporary band-aid, but in the longer term it is desirable
for the driver to be able to work without any kind of VRAM.
This patch adds a few conditionals in places where a RAM device was
assumed to be present and allows some more objects to be allocated from
the TT domain, allowing Nouveau to handle GPUs for which
pfb->ram == NULL.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Notify interrupt is only used for cyclestats. We can just clear it and
avoid an "unknown stat" error that gets printed to dmesg otherwise.
Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Other methods in this file suggest this is the correct way to retrieve
the engine pointer.
Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This if statement is correct but it wasn't indented, so it looked like
some code was missing.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
