- 11 May, 2017 9 commits
-
-
Ben Skeggs authored
The idea here was to avoid having to "manually" program the HW if there's a new earliest alarm. This was lazy and bad, as it leads to loads of fun races between inter-related callers (ie. therm). Turns out, it's not so difficult after all. Go figure ;) Signed-off-by:Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
Ben Skeggs authored
At least therm/fantog "attempts" to work around this issue, which could lead to corruption of the pending alarm list. Fix it properly by not updating the timestamp without the lock held, or trying to add an already pending alarm to the pending alarm list.... Signed-off-by: -
Ben Skeggs authored
If the time to the next alarm is short enough, we could race with HW and end up with an ~4 second delay until it triggers. Fix this by checking again after we update HW. Signed-off-by: -
Ben Skeggs authored
Fixes a race where we can miss an alarm that triggers while we're already processing previous alarms. Signed-off-by: -
Ben Skeggs authored
object->engine cannot be NULL, it's either valid, or an error pointer. This particular condition shouldn't actually be possible, but just in case, we'll keep it. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Ben Skeggs authored
This reg has moved on Pascal, and causes a bus fault. We never use the value anyway, so just remove the read. Signed-off-by: -
Ben Skeggs authored
The DRM core used to only call prepare_fb/cleanup_fb() when a plane's framebuffer changed, which achieved the desired effect. It's apparently now up to the driver to decide on its own. Signed-off-by: -
Ben Skeggs authored
This "optimisation" (which was originally meant to skip updating cursor settings in the core channel on position-only updates) turned out to be pointless in the final design of the code before it was merged. Remove it completely, as it breaks other cases. Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
- 29 Apr, 2017 5 commits
-
-
Mario Kleiner authored
A missing u64 cast causes a 32-Bit wraparound from 4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected if card has 4096 Mib per FBP. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
-
Wei Yongjun authored
The error return code PTR_ERR(mc) is always 0 since mc is equal to 0 in this error handling case. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Mario Kleiner authored
So far we only allowed for 1 retry and just failed the query - and thereby high precision vblank timestamping - if we did not get a reasonable result, as such a failure wasn't considered all too horrible. There are a few NVidia gpu models out there which may need a bit more than 1 retry to get a successful query result under some conditions. Since Linux 4.4 the update code for vblank counter and timestamp in drm_update_vblank_count() changed so that the implementation assumes that high precision vblank timestamping of a kms driver either consistently succeeds or consistently fails for a given video mode and encoder/connector combo. Iow. switching from success to fail or vice versa on a modeset or connector change is ok, but spurious temporary failure for a given setup can confuse the core code and potentially cause bad miscounting of vblanks and confusion or hangs in userspace clients which rely on vblank stuff, e.g., desktop compositors. Therefore change the max retry count to a larger number - more than any gpu so far is known to need to succeed, but still low enough so that these queries which do also happen in vblank interrupt are still fast enough to be not disastrously long if something would go badly wrong with them. As such sporadic retries only happen seldom even on affected gpu's, this could mean a vblank irq could take a few dozen microseconds longer every few hours of uptime -- better than a desktop compositor randomly hanging every couple of hours or days of uptime in a hard to reproduce manner. Signed-off-by:
-
Ben Skeggs authored
Fixes OOB VBIOS accesses on some boards. Signed-off-by: -
Ilia Mirkin authored
Signed-off-by:Ilia Mirkin <imirkin@alum.mit.edu>
-
- 06 Apr, 2017 23 commits
-
-
Adam Borowski authored
The code attempts to enable them, but hits an undefined behaviour by shifting by the entire register's width: int lines = 32; u32 mask = (1 << lines) - 1; // 00000000 on x86 u32 mask = (1 << lines) - 1; // ffffffff on arm (32) u32 mask = (1 << lines) - 1; // 00000000 on arm64 u32 mask = (1ULL << lines) - 1; // ffffffff everywhere Signed-off-by:Adam Borowski <kilobyte@angband.pl> Signed-off-by:
-
Ben Skeggs authored
Forked from GP106 implementation. Differences: - 1 PPC/GPC - Slightly different grctx magics Signed-off-by: -
Alexandre Courbot authored
Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
-
Alexandre Courbot authored
Signed-off-by:
-
Alexandre Courbot authored
GP10B's power is managed by generic PM domains, so it does not require a VDD regulator. Add this option into the chip function structure. Signed-off-by:
-
Alexandre Courbot authored
GR is similar to GP100, with a few unavailable registers. Signed-off-by:
-
Alexandre Courbot authored
GP10B requires a specific initialization sequence due to the absence of devinit. Signed-off-by:
-
Alexandre Courbot authored
GP10B's MC is compatible with GP100's, but engines need to be explicitly put out of ELPG during init. Signed-off-by:
-
Alexandre Courbot authored
GP10B's FB is largely compatible with the GP100 implementation. Signed-off-by:
-
Alexandre Courbot authored
GP10B's FIFO is similar to GP100's, but only allows 512 channels. Signed-off-by:
-
Alexandre Courbot authored
The GP10B firmware is very close to GM20B's. The only difference is that it supports booting multiple falcons. In order to avoid having too much functions and structures shared, implement its support in the same source file as GM20B firmware. Signed-off-by:
-
Alexandre Courbot authored
GP10B's secboot is largely similar to GM20B's. Only differences are MC base address and the fact that GPCCS is also securely managed. Signed-off-by:
-
Alexandre Courbot authored
Allow the MC base address to be specified as an argument for the WPR region reading function. GP10B uses a different address layout as GM20B, so this is necessary. Also export the function to be used by GP10B. Signed-off-by:
-
Alexandre Courbot authored
The LS firmware post-run hook is the right place to start said LS firmware. Moving it here also allows to remove special handling in the ACR code. Signed-off-by:
-
Alexandre Courbot authored
A LS post-run hook can meet an error meaning the failure of secure boot. Make sure this can be reported. Signed-off-by:
-
Alexandre Courbot authored
Having access to the secboot instance loading a LS firmware can be useful to LS firmware handlers. At least more useful than just having an out-of-context subdev pointer. GP10B's firmware will also need to know the WPR address, which can be obtained from the secboot instance. Signed-off-by:
-
Alexandre Courbot authored
Change the secboot and msgqueue interfaces to take a mask of falcons to reset instead of a single falcon. The GP10B firmware interface requires FECS and GPCCS to be booted in a single firmware command. For firmwares that only support single falcon boot, it is trivial to loop over the mask and boot each falcons individually. Signed-off-by:
-
Thierry Reding authored
The gk20a implementation of instance memory uses vmap()/vunmap() to map memory regions into the kernel's virtual address space. These functions may sleep, so protecting them by a spin lock is not safe. This triggers a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this by using a mutex instead. Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Ben Skeggs authored
Forked from GP106 implementation. Split out from commit enabling secboot/gr support so that it can be added to earlier kernels. Cc: stable@vger.kernel.org [4.10+] Signed-off-by: -
Ben Skeggs authored
When the atomic support was added to nouveau, the DRM core did not do this. However, later in the same merge window, a commit (drm/fence: add in-fences support) was merged that added it, leading to use-after-frees of the fence object. Cc: stable@vger.kernel.org [4.10+] Signed-off-by: -
Ben Skeggs authored
Cc: stable@vger.kernel.org [4.10+] Signed-off-by: -
Ilia Mirkin authored
The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP and PCI varieties, rather than a core PCIE chip with a bridge for AGP/PCI as necessary. As a result, it appears that the MMU is also non-functional. For AGP cards, the vast majority of the NV4A lineup, this worked out since we force AGP cards to use the nv04 mmu. However for PCI variants, this did not work. Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for the suggestion. This should be a no-op for NV4A AGP boards, as they were using it already. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388Signed-off-by:
-
Ilia Mirkin authored
Signed-off-by:
-
- 04 Apr, 2017 3 commits
-
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
RCAR GEN3 DU HDMI support. * 'drm/next/du' of git://linuxtv.org/pinchartl/media: (22 commits) drm: rcar-du: Add HDMI outputs to R8A7795 device description drm: rcar-du: Add DPLL support drm: rcar-du: Skip disabled outputs drm: rcar-du: Add Gen3 HDMI encoder support dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings drm: rcar-du: Hardcode encoders types to DRM_MODE_ENCODER_NONE drm: rcar-du: Replace manual bridge implementation with DRM bridge drm: rcar-du: Add support for LVDS mode selection drm: rcar-du: Use the DRM panel API drm: rcar-du: Document the vsps property in the DT bindings drm: rcar-du: Remove wait field from rcar_du_device structure drm: rcar-du: Make sure the VSP is initialized on platforms that need it drm: rcar-du: Use DRM core's atomic commit helper drm: rcar-du: Clear handled event pointer in CRTC state drm: rcar-du: Handle event when disabling CRTCs drm: rcar-du: Don't open code of_device_get_match_data() drm: rcar-du: Switch to encoder .atomic_mode_set() helper function drm: panels: Add LVDS panel driver drm: Add data transmission order bus flag devicetree/bindings: display: Add bindings for two Mitsubishi panels ...
-
Koji Matsuoka authored
Update the device description with the two available HDMI outputs. Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Koji Matsuoka authored
The implementation hardcodes a workaround for the H3 ES1.x SoC regardless of the SoC revision, as the workaround can be safely applied on all devices in the Gen3 family without any side effect. Signed-off-by:
Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by:
-
