summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
* drm/nouveau/core: fix static checker warningBen Skeggs2017-05-121-1/+1
| | | | | | | | | | 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 <bskeggs@redhat.com>
* drm/nouveau/fb/ram/gf100-: remove 0x10f200 readBen Skeggs2017-05-121-1/+0
| | | | | | | | 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 <bskeggs@redhat.com>
* drm/nouveau/kms/nv50: skip core channel cursor update on position-only changesBen Skeggs2017-05-121-3/+7
| | | | | | | | | | 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 <bskeggs@redhat.com> Cc: stable@vger.kernel.org [4.11+]
* drm/nouveau/kms/nv50: fix source-rect-only plane updatesBen Skeggs2017-05-121-5/+3
| | | | | | | | | | | 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 <bskeggs@redhat.com> Cc: stable@vger.kernel.org [4.10+]
* drm/nouveau/kms/nv50: remove pointless argument to window atomic_check_acquire()Ben Skeggs2017-05-121-7/+6
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detectionMario Kleiner2017-04-291-1/+1
| | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot/gm20b: fix the error return code in ↵Wei Yongjun2017-04-291-1/+1
| | | | | | | | | | gm20b_secboot_tegra_read_wpr() 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/kms: Increase max retries in scanout position queries.Mario Kleiner2017-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bios/bitP: check that table is long enough for optional pointersBen Skeggs2017-04-295-5/+5
| | | | | | Fixes OOB VBIOS accesses on some boards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engineIlia Mirkin2017-04-291-0/+2
| | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
* drm/nouveau/gpio: enable interrupts on cards with 32 gpio linesAdam Borowski2017-04-061-1/+1
| | | | | | | | | | | | | | 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 <bskeggs@redhat.com>
* drm/nouveau/gr/gp107: initial supportBen Skeggs2017-04-069-8/+120
| | | | | | | | | | Forked from GP106 implementation. Differences: - 1 PPC/GPC - Slightly different grctx magics Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: recognise GP10B chipsetAlexandre Courbot2017-04-061-0/+24
| | | | | Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/platform: support for probing GP10BAlexandre Courbot2017-04-061-0/+10
| | | | | Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/platform: make VDD regulator optionalAlexandre Courbot2017-04-063-9/+28
| | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr: support for GP10BAlexandre Courbot2017-04-066-2/+77
| | | | | | | GR is similar to GP100, with a few unavailable registers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/ibus: add GP10B supportAlexandre Courbot2017-04-063-0/+61
| | | | | | | | GP10B requires a specific initialization sequence due to the absence of devinit. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mc: add GP10B supportAlexandre Courbot2017-04-065-5/+69
| | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fb: add GP10B supportAlexandre Courbot2017-04-063-0/+40
| | | | | | | GP10B's FB is largely compatible with the GP100 implementation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo: add GP10B supportAlexandre Courbot2017-04-065-1/+45
| | | | | | | GP10B's FIFO is similar to GP100's, but only allows 512 channels. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/msgqueue: support for GP10B PMU firmwareAlexandre Courbot2017-04-063-0/+117
| | | | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: add GP10B supportAlexandre Courbot2017-04-063-0/+95
| | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot/gm20b: specify MC base address as argumentAlexandre Courbot2017-04-062-8/+12
| | | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: start LS firmware in post-run hookAlexandre Courbot2017-04-062-49/+47
| | | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: let LS post_run hooks return errorAlexandre Courbot2017-04-064-10/+26
| | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: pass instance to LS firmware loadersAlexandre Courbot2017-04-0612-39/+44
| | | | | | | | | | | | 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 <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: allow to boot multiple falconsAlexandre Courbot2017-04-068-28/+54
| | | | | | | | | | | | 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: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/imem/gk20a: Turn instmem lock into mutexThierry Reding2017-04-061-11/+8
| | | | | | | | | | | | | 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: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: initial support (display-only) for GP107Ben Skeggs2017-04-061-0/+30
| | | | | | | | | | 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 <bskeggs@redhat.com>
* drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane stateBen Skeggs2017-04-061-2/+0
| | | | | | | | | | | 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 <bskeggs@redhat.com>
* drm/nouveau/kms/nv50: fix setting of HeadSetRasterVertBlankDmi methodBen Skeggs2017-04-061-3/+5
| | | | | Cc: stable@vger.kernel.org [4.10+] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 oneIlia Mirkin2017-04-061-1/+1
| | | | | | | | | | | | | | | | | | 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=70388 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mpeg: mthd returns true on success nowIlia Mirkin2017-04-062-2/+2
| | | | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm: rcar-du: Add HDMI outputs to R8A7795 device descriptionKoji Matsuoka2017-04-042-3/+13
| | | | | | | 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>
* drm: rcar-du: Add DPLL supportKoji Matsuoka2017-04-044-1/+105
| | | | | | | | | | 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: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Skip disabled outputsLaurent Pinchart2017-04-041-0/+7
| | | | | | | When a DT node connected to a DU output is disabled no bridge will ever be instantiated for it. Skip the output in that case. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Add Gen3 HDMI encoder supportKoji Matsuoka2017-04-043-0/+108
| | | | | | | | | | | | | | The R-Car Gen3 SoCs include on-chip DesignWare HDMI encoders. Support them with a platform driver to provide platform glue data to the dw-hdmi driver. The driver is a complete rewrite of code coming from the Renesas BSP, save for the values in the PHY parameters table. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
* drm: rcar-du: Hardcode encoders types to DRM_MODE_ENCODER_NONELaurent Pinchart2017-04-045-82/+11
| | | | | | | | | | Unlike the connector type, the encoder type is unused by userspace. As it is equally unused in the driver, except in a single location where the connector type can be used instead, hardcode it to DRM_MODE_ENCODER_NONE. This allow removing all code that tries to determine (unsuccessfully in case a bridge is used) the encoder type. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Replace manual bridge implementation with DRM bridgeLaurent Pinchart2017-04-048-331/+60
| | | | | | | The rcar-du driver contains a manual implementation of HDMI and VGA bridges. Use DRM bridges to replace it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Add support for LVDS mode selectionLaurent Pinchart2017-04-043-2/+49
| | | | | | | | | Retrieve the LVDS mode from the panel and configure the LVDS encoder accordingly. LVDS mode selection is static as LVDS panels can't be hot-plugged on any of the device supported by the driver. Support for dynamic mode selection can be implemented in the future when needed. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Use the DRM panel APILaurent Pinchart2017-04-044-44/+50
| | | | | | | Instead of parsing the panel device tree node manually, use the panel API to delegate panel handling to a panel driver. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Remove wait field from rcar_du_device structureLaurent Pinchart2017-04-042-7/+0
| | | | | | | The field is a left-over from the switch to the atomic commit helper. It's unused, remove it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Make sure the VSP is initialized on platforms that need itJacopo Mondi2017-04-041-1/+1
| | | | | | | | | | | | | On Gen3 platforms planes are managed by the external VSP compositor on behalf of DRM/KMS. If VSP compositor support is not enabled in the DU driver, the VSP initialization stub routine is called. Return an error from that stub to fail explicitly, otherwise the device won't be usable and the driver will crash. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Clarified commit message] Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Use DRM core's atomic commit helperLaurent Pinchart2017-04-041-90/+9
| | | | | | | The DRM core atomic helper now supports asynchronous commits natively. The custom rcar-du implementation isn't needed anymore, remove it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Clear handled event pointer in CRTC stateLaurent Pinchart2017-04-041-3/+3
| | | | | | | | The atomic commit helper requires drivers to clear the event pointer stored in the CRTC state when the event is handled. In preparation to using the helper, fix the driver. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Handle event when disabling CRTCsLaurent Pinchart2017-04-041-0/+7
| | | | | | | | | The driver currently handles vblank events only when updating planes on a CRTC. The atomic update API however allows requesting an event when disabling a CRTC. This currently leads to event objects being leaked in the kernel and to events not being sent out. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: rcar-du: Don't open code of_device_get_match_data()Wolfram Sang2017-04-041-1/+1
| | | | | | | | | | | This change will also make Coverity happy by avoiding a theoretical NULL pointer dereference; yet another reason is to use the above helper function to tighten the code and make it more readable. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* drm: rcar-du: Switch to encoder .atomic_mode_set() helper functionLaurent Pinchart2017-04-042-8/+8
| | | | | | | The native encoder mode set helper function for atomic drivers is .atomic_mode_set(). Replace the legacy .mode_set() implementation. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm: panels: Add LVDS panel driverLaurent Pinchart2017-04-043-0/+297
| | | | | | | | This driver supports LVDS panels that don't require device-specific handling of power supplies or control signals. It implements automatic backlight handling if the panel is attached to a backlight controller. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* drm/omap: Major omap_modeset_init() cleanupJyri Sarha2017-04-034-139/+86
| | | | | | | | | | | | | | | | Cleanup overly complex omap_modeset_init(). The function is trying to support many unusual configuration, that have never been tested and are not supported by other parts of the dirver. After cleanup the init function creates exactly one connector, encoder, crtc, and primary plane per each connected dss-device. Each connector->encoder->crtc chain is expected to be separate and each crtc is connect to a single dss-channel. If the configuration does not match the expectations or exceeds the available resources, the configuration is rejected. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OpenPOWER on IntegriCloud