drm/nouveau: Fix drm poll_helper handling

Commit cae9ff036eea effectively disabled the drm poll_helper by checking
the wrong flag to see if the driver should enable the poll or not:
mode_config.poll_enabled is only set to true by poll_init and it is not
indicating if the poll is enabled or not.
nouveau_display_create() will initialize the poll and going to disable it
right away. After poll_init() the mode_config.poll_enabled will be true,
but the poll itself is disabled.

To avoid the race caused by calling the poll_enable() from different paths,
this patch will enable the poll from one place, in the
nouveau_display_hpd_work().

In case the pm_runtime is disabled we will enable the poll in
nouveau_drm_load() once.

Fixes: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on runtime resume")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lyude <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: remove ineffective workarounds for alarm bugs

These were ineffective due to touching the list without the alarm lock,
but should no longer be required.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

drm/nouveau/tmr: avoid processing completed alarms when adding a new one

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

drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm

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 <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

drm/nouveau/tmr: handle races with hw when updating the next alarm time

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 <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

drm/nouveau/tmr: ack interrupt before processing alarms

Fixes a race where we can miss an alarm that triggers while we're already
processing previous alarms.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

drm/nouveau/core: fix static checker warning

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 read

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 changes

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 updates

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()

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection

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 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.

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 pointers

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 engine

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

drm/nouveau/gpio: enable interrupts on cards with 32 gpio lines

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 support

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 chipset

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/platform: support for probing GP10B

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/platform: make VDD regulator optional

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 GP10B

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 support

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 support

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 support

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 support

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 firmware

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 support

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 argument

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 hook

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 error

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 loaders

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 falcons

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 mutex

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 GP107

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 state

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 method

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 one

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 now

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>

Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/media into drm-next

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
  ...

drm: rcar-du: Add HDMI outputs to R8A7795 device description

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 support

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 outputs

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 support

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>

dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings

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>

drm: rcar-du: Hardcode encoders types to DRM_MODE_ENCODER_NONE

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 bridge

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 selection

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 API

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: Document the vsps property in the DT bindings

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>

drm: rcar-du: Remove wait field from rcar_du_device structure

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 it

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 helper

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 state

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 CRTCs

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()

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 function

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 driver

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: Add data transmission order bus flag

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>

devicetree/bindings: display: Add bindings for two Mitsubishi panels

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>

devicetree/bindings: display: Add bindings for LVDS panels

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>

devicetree/bindings: display: Document common panel properties

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>

Merge tag 'omapdrm-4.12' of git://git./linux/kernel/git/tomba/linux into drm-next

omapdrm changes for 4.12

Main changes include:

* Add support for render nodes.
* Refactor omapdss code to allow multiple DISPC implementations. This is pre-work for DSS6 support.
* Fix replication logic bug, which caused RGB565 fb to be shown too dark on a 24bit display.
* Improve detection of display stack readiness, which should remove the probe order issues.
* Link panel-dpi with its backlight, so that they are turned on/off in sync.
* Fix possibly incorrect setup of sync and data-enable signals.
* Get rid of DRM_OMAP_NUM_CRTCS config option.

* tag 'omapdrm-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (34 commits)
  drm/omap: Major omap_modeset_init() cleanup
  drm/omap: Remove the obsolete #define omap_plane _omap_plane hack
  drm/omap: Fix one ugly indentation style break left by coccinelle
  drm/omap: Rename enum omap_plane to enum omap_plane_id
  drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option
  drm/omap: fix crash on module unload
  drm/omap: use drm_atomic_helper_shutdown()
  drm/omap: fix display SYNC/DE flags
  drm/omap: dispc: improve debug print of display flags
  drm/omap: displays: panel-dpi: Support for handling backlight devices
  drm/omap: poll only connectors where the connect/disconnect can be checked
  drm/omap: display: Add displays in sorted order to the panel_list
  drm/omap: Use omapdss_stack_is_ready() to check that the display stack is up
  drm/omap: dss: Support for detecting display stack readiness
  drm/omap: dss: Functions to check components in the display/output list
  drm/omap: fix replication logic
  drm/omap: remove unused dispc_wb_enable & dispc_wb_is_enabled
  drm/omap: remove all EXPORT_SYMBOLs from dispc.c
  drm/omap: use dispc_ops
  drm/omap: fill dispc_ops
  ...

drm/omap: Major omap_modeset_init() cleanup

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>

drm/omap: Remove the obsolete #define omap_plane _omap_plane hack

Remove the obsolete "#define omap_plane _omap_plane" hack and other
related hacks to get around the enum omap_plane colliding with struct
omap_plane.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Fix one ugly indentation style break left by coccinelle

Fix one ugly indentation style break left by the previous coccilnelle
patch.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Rename enum omap_plane to enum omap_plane_id

The enum omap_plane conflicted with the same struct name for omapdrm
plane private data. This rename should solve the conflict.

The rename was implement with this very simple coccinelle patch:
------------------------
@@
@@
enum
-omap_plane
+omap_plane_id
------------------------
The patch was applied like this:
spatch --sp-file <cocci_file> --all-includes --in-place --dir drivers/gpu/drm/omapdrm

The above patch did not rename the actual enum definition. That was
added manually on top of the spatch changes.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option

Allocate one CRTC for each connected output and get rid of
DRM_OMAP_NUM_CRTCS config option. We still can not create more CRTCs
than we have DSS display managers. We also reserve one overlay per
CRTC for primary plane so we can not have more CRTCs than we have
overlays either.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: fix crash on module unload

When unloading omapdrm we get a NULL pointer deref in
omap_drm_irq_uninstall(). This is caused by:

967dd48417874dd25491a4e933648f394a64f70f ("drm: remove
drm_vblank_no_hw_counter assignment from driver code")

We shut down all the crtcs at unload time before calling
omap_drm_irq_uninstall, so the code in omap_drm_irq_uninstall() is
unnecessary and can be removed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: use drm_atomic_helper_shutdown()

Use drm_atomic_helper_shutdown() to ensure that all crtcs are disabled
when unloading the driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: fix display SYNC/DE flags

At the moment VSYNC/HSYNC/DE high/low flags set by the panel/encoder
drivers get lost when the videotimings are translated to DRM's
videomode, as DRM's mode does not have corresponding flags.

DRM has bus-flags for this purpose, and while it lacks a few flags at
the moment, it should be used here. However, until we rewrite omapdrm's
device model, using bus-flags is rather difficult.

As a short term fix, this patch makes sure that every time the videomode
is set in omap_crtc_mode_set_nofb(), the driver asks for the SYNC/DE
flags from the panel/encoder drivers, and thus we get the correct flags
into use.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: dispc: improve debug print of display flags

Instead of printing 0/1 for display flags like vsync high/low, use a
tri-state print (-1/0/1) to indicate the "undefined" state.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: displays: panel-dpi: Support for handling backlight devices

The associated backlight device can be configured via DT by providing the
phandle to the device.

If the backlight device is configured, the driver can manage the backligt
along with the panel's power state, iow it can turn on the backlight when
the panel is enabled and turn it off when the panel is disabled.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: poll only connectors where the connect/disconnect can be checked

When the connector associated detect callback is not provided, we can not
detect if the display is connected or disconnected. These displays do not
support hot plug, they are always connected. Let DRM know that connectors
w/o detect callback should not be polled.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: display: Add displays in sorted order to the panel_list

Keep the panel_list ordered according to aliases. The DRM connectors will
be created following the panel_list. By keeping the list ordered the DRM
connectors will be created in the same order regardless of the driver
probe order.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Use omapdss_stack_is_ready() to check that the display stack is up

Instead of 'guessing' based on aliases of the status of the DSS drivers,
use the new interface to check that all needed drivers are loaded.
In this way we can be sure that all needed drivers are loaded so it is
safe to continue the probing of omapdrm.
This method will allow the omapdrm to be probed 'headless', without
outputs.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: dss: Support for detecting display stack readiness

When omapdss is loaded (all core components are in place) create a list of
devices used in the display graph. This list later can be used by omapdrm
via the omapdss_stack_is_ready() function to check that these components
are loaded. Based on this information, omapdrm can defer probe in case when
the omapdss stack is not ready yet.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: dss: Functions to check components in the display/output list

The functions can be used to check a component (by it's of_node) if it is
part of the omapdss display or output list. If the component is found, it
means that the driver is loaded.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: fix replication logic

DSS uses "replication logic" to convert color components from smaller
bit widths to bigger bit widths. Without replication logic, the color
component would be shifted and the least significant bits would be left
at 0, whereas with replication logic, the least significat bits will be
filled with the most significant bit.

For some reason omapdrm leaves replication logic always to off, which,
in the most common case, means that showing 16-bit RGB colors on 24-bit
display gives a bit darker colors than expected.

The reset value of the replication logic bit is enabled, and it should
always be set, as there's no practical reason to disable it. This patch
removes the option to disable it from omapdrm, and always sets it to
enabled in dispc.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: remove unused dispc_wb_enable & dispc_wb_is_enabled

Remove two unused WB functions.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: remove all EXPORT_SYMBOLs from dispc.c

omapdrm now uses dispc_ops instead of direct function calls so we can
remove all EXPORT_SYMBOLs from dispc. Most of the functions can also be
made static, but a few are used outside dispc.c.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: use dispc_ops

Change omapdrm to get dispc_ops and use that to call the dispc functions
instead or direct function calls.

The change is very straightforward.

The only problem was in omap_crtc_init() which calls pipe2vbl(crtc), and
at that point of time the crtc->dev link, which is used to get the
dispc_ops, has not been set up yet. This patch makes omap_crtc_init()
skip the call to pipe2vbl() and instead calls
dispc_ops->mgr_get_vsync_irq() directly.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: fill dispc_ops

This patch changes the current omapdss driver to fill a dispc_ops struct
and set it to omapdss-base.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: add dispc_ops

We want to change the dispc API from plain functions to a struct with
functions pointers, so that omapdrm can call either omapdss or omapdss6
depending on the platform.

This patch adds 'struct dispc_ops' and adds functions to omapdss-base
to set and get the ops.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: move dispc related dss-feat funcs to dispc

omapdrm still uses a few non-dispc functions: dss_feat_get_num_mgrs(),
dss_feat_get_num_ovls() and  dss_feat_get_supported_color_modes(). We
want to provide omapdrm a single dispc_ops function pointer struct so
that omapdrm will use either the current omapdss or the new omapdss6
driver depending on the platform.

Those three functions are really dispc functions, but are located in the
dss_features.c for legacy reasons.

This patch adds similar functionss to the dispc, and changes omapdrm to
use those new functions. Underneath the functions still call the
functions from dss_feature.c.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: move display, dss-of, output to omapdss-base

This patch moves the common parts of omapdss to omapdss-base so that
both the current omapdss driver and the new omapdss6 driver can use
them.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: display: don't use dsi_get_pixel_size()

display.c uses dsi_get_pixel_size() which is implemented in the DSI
driver, and we won't have that in the omapdss-base module, to which we
want to move display.c

This patch changes display.c not to use dsi_get_pixel_size(). The call
can be replaced with a simple check for OMAP_DSS_DSI_FMT_RGB565.

We can also make dsi_get_pixel_size() static as it's no longer used
outside dsi.c.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: output: use dev_err instead of DSSERR

We don't have omapdss's custom error printing functions in the common
omapdss-base module, to which we want to move output.c.

This patch changes output.c to use dev_err instead of DSSERR so that it
doesn't depend on DSSERR.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: move dss_initialized to omapdss-base

omapdss_is_initialized() is used to find out if omapdss has been probed
successfully. This patch moves the related code to the common
omapdss-base module, so that the same support will be there for both
omapdss and omapdss6.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: add omapdss-base.ko

We are working towards enabling omapdss6, which will consists of a new
dss, dispc and dpi drivers. omapdss6 will be a new module. The panel,
encoder and omapdrm will need to use either the current omapdss driver
or the new omapdss6 driver, depending on the platform.

This will be implemented with a common base module and function
pointers.

This patch adds a skeleton omapdss-base.ko module, to which we'll be
moving common dss functionality like registration of the panels.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: fix HDMI sync polarities

While implementing writeback support, odd behavior of WBDELAYCOUNT was
observed with the combination of WB capture and HDMI. The result of the
debugging was that the HDMI sync polarities are not set correctly.

The current code sets the sync polarities going from HDMI WP to DISPC
according to the video mode used, which seems to work normally fine, but
causes problems with WB as WB expects the syncs to be active-high.

This patch changes the HDMI sync polarities so that the DISPC always
gets active-high syncs from HDMI WP, and the HDMI core gets sync
polarities according to the used video mode.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: Add support for render nodes

Add support for render nodes in omap driver and allow required
ioctls to be accessible via render nodes.

This enables unprivileged clients to allocate resources like GEM buffers
for rendering their content into. Mode setting (KMS ioctls) is not
allowed using render nodes. These buffers are then shared with
a previleged process (e.g compositor) that has mode setting access.

An example of this use case is Android where the hardware composer is
the only master and has mode setting access. Every other client then
uses render node(e.g /dev/dri/renderD128 to allocate and use its buffers.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: improve DPI clock selection on DRA7xx

The clock source selection for the LCD outputs is too hardcoded at the
moment. For example, LCD3 is set to use PLL2_1, and PLL2 doesn't exist
on DRA72x SoCs.

There are quite many ways to configure the clocks, even using HDMI PLL
for LCD outputs, but enabling full configuration of the clocks is rather
tricky.

This patch improves the situation a bit by checking if the PLL about to
be used exists, and if not, tries another one.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: decrease min width & height

mode_config's min_width and min_height are both set to 32, which is
overly restrictive.

The real limits depend on whether we're configuring a crtc or a plane,
but a limit of 8x2 is safe for both cases.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: remove divider constraint from hsdiv

The driver only uses even dividers for hsdiv when pclk >= 100MHz, as odd
dividers can create uneven duty cycle. However, while this holds true
for some dividers like DISPC's LCK and PCK dividers, it is not actually
true for hsdiv.

hsdiv always produces even duty cycle, so the constraint can be removed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

drm/omap: refactor CRTC HW property setup

The current driver doesn't expose any of the CRTC HW properties like
background color or transparency key, and sets them at CRTC enable time.

Refactor this into a separate function and call that function from
omap_crtc_atomic_flush(). This is the behavior we want when the
properties can be configured, so this patch makes it easier to add
patches later which implement those properties.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: work-around for errata i886

DRA7 errata i886 (FPDLink PLL Unlocks With Certain SoC PLL M/N Values)
says that FPDLink is sensitive to jitter on the vout clock, and that low
PLL M and N values result in more jitter than high M and N values.

This patch implements a workaround for the problem by changing the PLL
setup to search for clocks starting from high M and N values, instead of
low values. This should not cause any functional change, and only
reduces the jitter.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Merge tag 'drm-misc-next-2017-03-31' of git://anongit.freedesktop.org/git/drm-misc into drm-next

drm-misc for 4.12:

Core:
- Removed some fb subsampling dimension checks from core (Ville)
- Some MST slot cleanup (Dhinakaran)
- Extracted drm_debugfs.h & drm_ioctl.h from drmP.h (Daniel)
- Added drm_atomic_helper_shutdown() to compliment suspend/resume counterparts
  (Daniel)
- Pipe context through legacy modeset to remove legacy_backoff nasties (Daniel)
- Cleanups around vblank as well as allowing lockless counter reads (Chris W.)
- VGA Switcheroo added to MAINTAINERS with Lukas Wunner as reviewer (Lukas)

Drivers:
- Enhancements to rockchip driver probe (Jeffy) and dsi (Chris Z.)
- Thunderbolt external GPU awareness added (Lukas)

* tag 'drm-misc-next-2017-03-31' of git://anongit.freedesktop.org/git/drm-misc: (63 commits)
  apple-gmux: Don't switch external DP port on 2011+ MacBook Pros
  drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo
  drm/amdgpu: Don't register Thunderbolt eGPU with vga_switcheroo
  drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo
  PCI: Recognize Thunderbolt devices
  MAINTAINERS: Add Lukas Wunner as reviewer for vga_switcheroo
  drm: Fix locking gotcha in page_flip ioctl
  drm: Clarify the role of plane_state argument to drm_simple update().
  drm: Clear e after kfree in drm_mode_page_flip_ioctl
  drm: Convert cmpxchg(bool) back to a two step operation
  drm/bridge: ti-tfp410: support hpd via gpio
  drm: use .hword to represent 16-bit numbers
  Revert unrelated part of "drm: simplify the locking in the GETCRTC ioctl"
  drm: Fixup failure paths in drm_atomic_helper_set_config
  drm: Peek at the current counter/timestamp for vblank queries
  drm: Refactor vblank sequence number comparison
  drm: vblank cannot be enabled if dev->irq_enabled is false
  drm: Mark up accesses of vblank->enabled outside of its spinlock
  drm: Make the decision to keep vblank irq enabled earlier
  drm/atomic-helper: Remove the backoff hack from set_config
  ...

Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next

This series enables atomic mode set for vmwgfx.  A number of features and
larger fixes are also included.

* 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux: (22 commits)
  drm/vmwgfx: Properly check display/scanout surface size
  drm/vmwgfx: Support topology greater than texture size
  drm/vmwgfx: Define an overlaid handle_close ioctl.
  drm/vmwgfx: Re-implement the stream resource as a simple resource.
  drm/vmwgfx: Introduce a simple resource type
  drm/vmwgfx: Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"
  drm/vmwgfx: Fix LDU X blank screen until mode change issue
  drm/vmwgfx: Skipping fbdev fb pinning for ldu
  drm/vmwgfx: Explicityly track screen target width and height
  drm/vmwgfx: Turn on DRIVER_ATOMIC flag
  drm/vmwgfx: Switch over to internal atomic API for SOU and LDU
  drm/vmwgfx: Switch over to internal atomic API for STDU
  drm/vmwgfx: Fixes to vmwgfx_fb
  drm/vmwgfx: Add and connect atomic state object check/commit
  drm/vmwgfx: Add and connect connector helper function
  drm/vmwgfx: Add and connect plane helper functions
  drm/vmwgfx: Add and connect CRTC helper functions
  drm/vmwgfx: Connector atomic state
  drm/vmwgfx: Plane atomic state
  drm/vmwgfx: CRTC atomic state
  ...

drm/vmwgfx: Properly check display/scanout surface size

The scanout surface size is the smaller of max texture size and
max STDU size.

Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>