Add a flag that can be set when declaring how a LS firmware should be
loaded. This allows us to remove falcon-specific code in the loader.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Split the act of building the ACR blob from firmware files from the rest
of the (chip-dependent) secure boot logic. ACR logic is moved into
acr_rxxx.c files, where rxxx corresponds to the compatible release of
the NVIDIA driver. At the moment r352 and r361 are supported since
firmwares have been released for these versions. Some abstractions are
added on top of r352 so r361 can easily be implemented on top of it by
just overriding a few hooks.
This split makes it possible and easy to reuse the same ACR version on
different chips. It also hopefully makes the code much more readable as
the different secure boot logics are separated. As more chips and
firmware versions will be supported, this is a necessity to not get lost
in code that is already quite complex.
This is a big commit, but it essentially moves things around (and split
the nvkm_secboot structure into two, nvkm_secboot and nvkm_acr). Code
semantics should not be affected.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the HS hook to completely generate the HS BL descriptor, similarly
to what is done in the LS hook, instead of (arbitrarily) using the
acr_v1 format as an intermediate.
This allows us to make the bootloader descriptor structures private to
each implementation, resulting in a cleaner an more consistent design.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Secure firmwares provided by NVIDIA will follow the same overall
principle, but may slightly differ in format, or not use the same
bootloader descriptor even on the same chip. In order to handle
this as gracefully as possible, turn the LS firmware functions into
hooks that can be overloaded as needed.
The current hooks cover the external firmware loading as well as the
bootloader descriptor generation.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This hook can be removed if the function writing the HS
descriptor is aware of WPR settings. Let's do that as it allows us to
make the ACR descriptor structure private and save some code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The init() hook is called by the subdev's oneinit(). Rename it
accordingly to avoid confusion about the lifetime of objects allocated
in it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since GR has moved to using the falcon library to start the falcons,
this function is not needed anymore.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Create instances for the FECS and GPCCS falcons and use the init() and
fini() hooks to reserve them for as long as GR controls them.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gf100_gr_init_ctxctl() is basically two different functions (one for
use of internal firmware, the other for use of external firmware), but
its current layout makes it look more complex than it is. Split it to
better reflect that fact.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a fini() hook to the GR engine. This will be used by gf100+ to
properly release the FECS and GPCCS falcons.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the falcon library functions in secure boot. This removes a lot of
code and makes the secure boot flow easier to understand as no register
is directly accessed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These functions should use the nvkm_secboot_falcon enum. Fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a dummy PMU device so the PMU falcon is instanciated and can be used
by secure boot.
We could reuse gk20a's implementation here, but it would fight with
secboot over PMU falcon's ownership and secboot will reset the PMU,
preventing it from operating afterwards. Proper handout between secboot
and pmu is coming along with the actual gm20b PMU implementation, so
use this as a temporary solution.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some functions always succeed - change their return type to void and
remove the error-handling code in their caller.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the PMU constructor so that all base members (in particular the
falcon instance) are initialized properly.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Have an instance of nvkm_falcon in the PMU structure, ready to be used
by other subdevs (i.e. secboot).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a PMU constructor so implementations that extend the nvkm_pmu
structure can have all base members properly initialized.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Falcon processors are used in various places of GPU chips. Although there
exist different versions of the falcon, and some variants exist, the
base set of actions performed on them is the same, which results in lots
of duplicated code.
This patch consolidates the current nvkm_falcon structure and extends it
with the following features:
* Ability for an engine to obtain and later release a given falcon,
* Abstractions for basic operations (IMEM/DMEM access, start, etc)
* Abstractions for secure operations if a falcon is secure
Abstractions make it easy to e.g. start a falcon, without having to care
about its details. For instance, falcons in secure mode need to be
started by writing to a different register.
Right now the abstractions variants only cover secure vs. non-secure
falcon, but more will come as e.g. SEC2 support is added.
This is still a WIP as other functions previously done by
engine/falcon.c need to be reimplemented. However this first step allows
to keep things simple and to discuss basic design.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a function that allows us to query whether a given subdev is
currently enabled or not.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Constify the local variables declared in these macros so we can pass
const pointers to them.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.
I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates. The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.
// <smpl>
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
// </smpl>
Changes since v1:
- Rebased on top of the tip of drm-misc-next.
- Remove mention to sti since a proper fix got merged.
Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
This is the main feature pull for radeon and amdgpu for 4.11. Highlights:
- Power and clockgating improvements
- Preliminary SR-IOV support
- ttm buffer priority support
- ttm eviction fixes
- Removal of the ttm lru callbacks
- Remove SI DPM quirks due to MC firmware issues
- Handle VFCT with multiple vbioses
- Powerplay improvements
- Lots of driver cleanups
* 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux: (120 commits)
drm/amdgpu: fix amdgpu_bo_va_mapping flags
drm/amdgpu: access stolen VRAM directly on CZ (v2)
drm/amdgpu: access stolen VRAM directly on KV/KB (v2)
drm/amdgpu: fix kernel panic when dpm disabled on Kv.
drm/amdgpu: fix dpm bug on Kv.
drm/amd/powerplay: fix regresstion issue can't set manual dpm mode.
drm/amdgpu: handle vfct with multiple vbios images
drm/radeon: handle vfct with multiple vbios images
drm/amdgpu: move misc si headers into amdgpu
drm/amdgpu: remove unused header si_reg.h
drm/radeon: drop pitcairn dpm quirks
drm/amdgpu: drop pitcairn dpm quirks
drm: radeon: radeon_ttm: Handle return NULL error from ioremap_nocache
drm/amd/amdgpu/amdgpu_ttm: Handle return NULL error from ioremap_nocache
drm/amdgpu: add new virtual display ID
drm/amd/amdgpu: remove the uncessary parameter for ib scheduler
drm/amdgpu: Bring bo creation in line with radeon driver (v2)
drm/amd/powerplay: fix misspelling in header guard
drm/ttm: revert "add optional LRU removal callback v2"
drm/ttm: revert "implement LRU add callbacks v2"
...
This somehow fixes an issue where sync-to-vblank longer works correctly
after resume from suspend.
From a HW perspective, we don't need the IRQs turned on to be able to
detect flip completion, so it's assumed that this is required for the
voodoo in the core DRM vblank core.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The proper fix would have been to select LEDS_CLASS but this can lead
to a circular dependency, as found out by Arnd.
This patch implements Arnd's suggestion instead, at the cost of some
auto-magic for a fringe feature.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Intel's 0-DAY
Fixes: 8d021d71b3 ("drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logo")
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The workaround appears to cause regressions on these boards, and from
inspection of RM traces, NVIDIA don't appear to do it on them either.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Roy Spliet <nouveau@spliet.org>
The additional housekeeping had too much CPU overhead,
let's use the BO priorities instead.
agd: also revert hibmc changes
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-and-Tested-by: Roger.He <Hongbo.He@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ensure that the driver can listen to evictions even when they don't take the
path through ttm_bo_driver::move.
This is crucial for amdgpu, which relies on an eviction counter to skip
re-binding page tables when possible.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.
This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:
- Get a machine with both optimus and a nvidia card with connectors
attached to it
- Wait for the nvidia GPU to suspend
- Attempt to manually reprobe any of the connectors on the nvidia GPU
using sysfs
- *deadlock*
[airlied: use READ_ONCE to address Hans's comment]
Signed-off-by: Lyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.
This fixes hangs observed on the ThinkPad W541
Signed-off-by: Lyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Back to regular -misc pulls with reasonable sizes:
- dma_fence error clarification (Chris)
- drm_crtc_from_index helper (Shawn), pile more patches on the m-l to roll
this out to drivers
- mmu-less support for fbdev helpers from Benjamin
- piles of kerneldoc work
- some polish for crc support from Tomeu and Benjamin
- odd misc stuff all over
* tag 'drm-misc-next-2017-01-09' of git://anongit.freedesktop.org/git/drm-misc: (48 commits)
dma-fence: Introduce drm_fence_set_error() helper
dma-fence: Wrap querying the fence->status
dma-fence: Clear fence->status during dma_fence_init()
drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"
drm: Change the return type of the unload hook to void
drm: add more document for drm_crtc_from_index()
drm: remove useless parameters from drm_pick_cmdline_mode function
drm: crc: Call wake_up_interruptible() each time there is a new CRC entry
drm: allow to use mmuless SoC
drm: compile drm_vm.c only when needed
fbmem: add a default get_fb_unmapped_area function
drm: crc: Wait for a frame before returning from open()
drm: Move locking into drm_debugfs_crtc_crc_add
drm/imx: imx-tve: Remove unused variable
Revert "drm: nouveau: fix build when LEDS_CLASS=m"
drm: Add kernel-doc for drm_crtc_commit_get/put
drm/atomic: Fix outdated comment.
drm: reference count event->completion
gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap
drm: Document deprecated load/unload hook
...
The integer returned by the unload hook is ignored by the drm core, so
let's make it void.
This patch was created using the following Coccinelle semantic script
(except for the declaration and comment in drm_drv.h):
Compile-tested only.
// <smpl>
@ get_name @
struct drm_driver drv;
identifier fn;
@@
drv.unload = fn;
@ replace_type @
identifier get_name.fn;
@@
- int
+ void
fn (...)
{
...
}
@ remove_return_param @
identifier get_name.fn;
@@
void fn (...)
{
<...
if (...)
return
- ...
;
...>
}
@ drop_final_return @
identifier get_name.fn;
@@
void fn (...)
{
...
- return 0;
}
// </smpl>
Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Acked-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170106175731.29196-1-krisman@collabora.co.uk
First -misc pull for 4.11:
- drm_mm rework + lots of selftests (Chris Wilson)
- new connector_list locking+iterators
- plenty of kerneldoc updates
- format handling rework from Ville
- atomic helper changes from Maarten for better plane corner-case handling
in drivers, plus the i915 legacy cursor patch that needs this
- bridge cleanup from Laurent
- plus plenty of small stuff all over
- also contains a merge of the 4.10 docs tree so that we could apply the
dma-buf kerneldoc patches
It's a lot more than usual, but due to the merge window blackout it also
covers about 4 weeks, so all in line again on a per-week basis. The more
annoying part with no pull request for 4 weeks is managing cross-tree
work. The -intel pull request I'll follow up with does conflict quite a
bit with -misc here. Longer-term (if drm-misc keeps growing) a
drm-next-queued to accept pull request for the next merge window during
this time might be useful.
I'd also like to backmerge -rc2+this into drm-intel next week, we have
quite a pile of patches waiting for the stuff in here.
* tag 'drm-misc-next-2016-12-30' of git://anongit.freedesktop.org/git/drm-misc: (126 commits)
drm: Add kerneldoc markup for new @scan parameters in drm_mm
drm/mm: Document locking rules
drm: Use drm_mm_insert_node_in_range_generic() for everyone
drm: Apply range restriction after color adjustment when allocation
drm: Wrap drm_mm_node.hole_follows
drm: Apply tight eviction scanning to color_adjust
drm: Simplify drm_mm scan-list manipulation
drm: Optimise power-of-two alignments in drm_mm_scan_add_block()
drm: Compute tight evictions for drm_mm_scan
drm: Fix application of color vs range restriction when scanning drm_mm
drm: Unconditionally do the range check in drm_mm_scan_add_block()
drm: Rename prev_node to hole in drm_mm_scan_add_block()
drm: Fix O= out-of-tree builds for selftests
drm: Extract struct drm_mm_scan from struct drm_mm
drm: Add asserts to catch overflow in drm_mm_init() and drm_mm_init_scan()
drm: Simplify drm_mm_clean()
drm: Detect overflow in drm_mm_reserve_node()
drm: Fix kerneldoc for drm_mm_scan_remove_block()
drm: Promote drm_mm alignment to u64
drm: kselftest for drm_mm and restricted color eviction
...
drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU.
Use a new DRM_VM to define when drm_vm.c in needed.
stub drm_legacy_vma_flush() to avoid compilation issues
version 4:
- a "config DRM_VM" in Kconfig
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
[danvet: Fix conflict.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit a5ad0fd852.
It results in kconfing complaining about recursive depencies:
drivers/usb/Kconfig:39:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/input/Kconfig:8: symbol INPUT is selected by VT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:128: symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/arm/Kconfig:6: symbol DRM_HDLCD depends on COMMON_CLK
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by X86_INTEL_QUARK
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/platform/x86/Kconfig:5: symbol X86_PLATFORM_DEVICES is selected by DRM_NOUVEAU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on LEDS_CLASS
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB
warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 &&
+BACKLIGHT_CLASS_DEVICE && INPUT)
And there's apparently a better patch available already.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
CONFIG_DRM_NOUVEAU=y.
If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
kconfig value as LEDS_CLASS.
drivers/built-in.o: In function `nouveau_do_suspend':
nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
drivers/built-in.o: In function `nouveau_do_resume':
nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
drivers/built-in.o: In function `nouveau_drm_unload':
nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
drivers/built-in.o: In function `nouveau_drm_load':
nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
BTW, this line in Kbuild:
nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Martin Peres <martin.peres@free.fr>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/029a1ec5-48ac-a3ce-3106-430e0f2584bb@infradead.org
ktime_set(S,N) was required for the timespec storage type and is still
useful for situations where a Seconds and Nanoseconds part of a time value
needs to be converted. For anything where the Seconds argument is 0, this
is pointless and can be replaced with a simple assignment.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
