- 06 4月, 2017 21 次提交
-
-
由 Alexandre Courbot 提交于
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
GR is similar to GP100, with a few unavailable registers. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
GP10B requires a specific initialization sequence due to the absence of devinit. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
GP10B's MC is compatible with GP100's, but engines need to be explicitly put out of ELPG during init. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
GP10B's FB is largely compatible with the GP100 implementation. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
GP10B's FIFO is similar to GP100's, but only allows 512 channels. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
A LS post-run hook can meet an error meaning the failure of secure boot. Make sure this can be reported. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Thierry Reding 提交于
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: NThierry Reding <treding@nvidia.com> Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com> Tested-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
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: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
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: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Cc: stable@vger.kernel.org [4.10+] Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
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: NIlia Mirkin <imirkin@alum.mit.edu> Cc: stable@vger.kernel.org Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Fixes: 590801c1 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 05 4月, 2017 1 次提交
-
-
git://linuxtv.org/pinchartl/media由 Dave Airlie 提交于
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 ...
-
- 04 4月, 2017 18 次提交
-
-
由 Koji Matsuoka 提交于
Update the device description with the two available HDMI outputs. Signed-off-by: NKoji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Koji Matsuoka 提交于
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: NKoji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Koji Matsuoka 提交于
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: NKoji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add corresponding device tree bindings based on the DWC HDMI TX bindings model. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: NRob Herring <robh@kernel.org>
-
由 Laurent Pinchart 提交于
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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The rcar-du driver contains a manual implementation of HDMI and VGA bridges. Use DRM bridges to replace it. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Instead of parsing the panel device tree node manually, use the panel API to delegate panel handling to a panel driver. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The property is used by the driver but is missing from the DT bindings. Document it. Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The field is a left-over from the switch to the atomic commit helper. It's unused, remove it. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Jacopo Mondi 提交于
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: NJacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Clarified commit message] Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The DRM core atomic helper now supports asynchronous commits natively. The custom rcar-du implementation isn't needed anymore, remove it. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Wolfram Sang 提交于
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: NWolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The native encoder mode set helper function for atomic drivers is .atomic_mode_set(). Replace the legacy .mode_set() implementation. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-