IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- The PRE/PRG drivers added an unwanted DRM dependency to the ipu-v3 driver.
Remove the dependency by conditionally disabling PRE/PRG support depending
on CONFIG_DRM.
- Merge the imx-ipuv3-crtc module into the imxdrm module. There is no reason
anymore for a separation between core drm driver and crtc/plane drivers,
especially since commit eb8c88808c83 ("drm/imx: add deferred plane
disabling"), which added a dependency on imx-ipuv3-crtc to the imxdrm
module.
-----BEGIN PGP SIGNATURE-----
iQJLBAABCAA1FiEEBsBxhV1FaKwXuCOBUMKIHHCeYOsFAljjxWwXHHAuemFiZWxA
cGVuZ3V0cm9uaXguZGUACgkQUMKIHHCeYOtLHg//aoq3/r65mlsCVo5DoWH8niOo
Po4nrCPPUbwieeG5q1kkjj/Yj8rwwPAL06GKzeeV4z1IdH1rmbNuJKbSej4EHyB9
S1WHZ5GtZLphVGKyvPVJOPnnsrKXY/O+VhmBAX6ww56uYBqEEsrNaNREz4QB1Kqc
JXtHBjwqO1DUJlLhJ105DutIjTendeJjQThRzjp8m95RGD1Xs6EwhtY4QLkbDRry
DK1MXqmGlOfl0C9rLMH9b0WvtCqu8DJ8M6X+7I0C5XI9fbOXrp9SvAPafxhV/y27
6CHmmfJiF4Wm7lNjpdDgJu5c4361S4NHiNHj0wJM+/BoplhaZliIxyuIgUY9C1Fj
uUG5pb74lus3m2n384xDk+AWvMbTubCdIS5xCgesCHJ2E8As+7z0Wbj5HV5vP4Zy
1j/jQaH07Yz/WgtdCQ7OYwVixFGMDnQAfTgdpiKI/d3ZD4m31lrZrvOhgQx9hF0c
FwPQ7RWPOK5GwYDxzs/6mO4Me1kva8uXCC7HJhPBaqgbfBYDQ88JoNOf4bMVIN63
cJxpNnUYdkVT8ViA97u7L7uUeZPhSYazdx/ncjGvjj/s5nl09ZegtgqxFSCQ8Q8n
eLdF0dkgqQ/es4dQMChdbUUiFRIFufhFJ05cK74tPh06+jy/XSbL3XlCHOMCX8oZ
ruyTYM0cqwGo9OqTkvc=
=3ZIW
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-next-2017-04-04' of git://git.pengutronix.de/git/pza/linux into drm-next
imx-drm module/dependency changes
- The PRE/PRG drivers added an unwanted DRM dependency to the ipu-v3 driver.
Remove the dependency by conditionally disabling PRE/PRG support depending
on CONFIG_DRM.
- Merge the imx-ipuv3-crtc module into the imxdrm module. There is no reason
anymore for a separation between core drm driver and crtc/plane drivers,
especially since commit eb8c88808c83 ("drm/imx: add deferred plane
disabling"), which added a dependency on imx-ipuv3-crtc to the imxdrm
module.
* tag 'imx-drm-next-2017-04-04' of git://git.pengutronix.de/git/pza/linux:
drm/imx: merge imx-drm-core and ipuv3-crtc in one module
gpu: ipu-v3: don't depend on DRM being enabled
A bit more for 4.12:
- GP10B support
- GP107 acceleration support
* 'linux-4.12' of git://github.com/skeggsb/linux: (23 commits)
drm/nouveau/gpio: enable interrupts on cards with 32 gpio lines
drm/nouveau/gr/gp107: initial support
drm/nouveau/core: recognise GP10B chipset
drm/nouveau/platform: support for probing GP10B
drm/nouveau/platform: make VDD regulator optional
drm/nouveau/gr: support for GP10B
drm/nouveau/ibus: add GP10B support
drm/nouveau/mc: add GP10B support
drm/nouveau/fb: add GP10B support
drm/nouveau/fifo: add GP10B support
drm/nouveau/msgqueue: support for GP10B PMU firmware
drm/nouveau/secboot: add GP10B support
drm/nouveau/secboot/gm20b: specify MC base address as argument
drm/nouveau/secboot: start LS firmware in post-run hook
drm/nouveau/secboot: let LS post_run hooks return error
drm/nouveau/secboot: pass instance to LS firmware loaders
drm/nouveau/secboot: allow to boot multiple falcons
drm/nouveau/imem/gk20a: Turn instmem lock into mutex
drm/nouveau: initial support (display-only) for GP107
drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane state
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
...
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>
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>
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>
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>
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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
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>
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>
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>
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>
The property is used by the driver but is missing from the DT bindings.
Document it.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
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>
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>
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>
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>
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>
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>
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>
The flags indicate whether data is transmitted LSB to MSB or MSB to LSB
on the bus.
The exact meaning is bus-type dependent. For instance, for LVDS buses
the flags indicate whether the seven data bits transmitted in a clock
pulse are sent in normal order (MSB to LSB, slots 0 to 6) or reverse
order (LSB to MSB, slots 6 to 0).
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
The AA104XD12 and AA121TD01 are LVDS display panels. Their bindings are
modelled on the the LVDS panel bindings.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple incompatible data link layers have been used over time to
transmit image data to LVDS panels. This binding supports display panels
compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
specifications.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
Document properties common to several display panels in a central
location that can be referenced by the panel device tree bindings.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
While it is possible to hook other CRTC implementations into imx-drm
in practice there are none yet and the option to disable ipuv3-crtc
support has been hidden for a long time.
Now that the imx-drm-core has learned to deal with some of the
specifics of IPUv3 there is a cyclic dependency between both parts.
To get rid of this and to decimate the Kconfig maze a bit, simply
merge both parts into one module.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The PRE/PRG drivers, which need the DRM infrastructure, are only used
from the output path, so we skip building them into the ipu-v3 driver
if CONFIG_DRM is not enabled.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
