Universal planes are ready to leave 'experimental' state so drop the
kernel command line parameter that we've been hiding them behind.
Userspace clients that wish to receive universal planes will still need
to opt-in by setting the appropriate capability bit, so this should have
no impact on existing userspace.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We introduced render-nodes about 1/2 year ago and no problems showed up.
Remove the drm_rnodes argument and enable them by default now.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

drm_gem_get_pages() currently allows passing a 'gfp' parameter that is
passed to shmem combined with mapping_gfp_mask(). Given that the default
mapping_gfp_mask() is GFP_HIGHUSER, it is _very_ unlikely that anyone will
ever make use of that parameter. In fact, all drivers currently pass
redundant flags or 0.

This patch removes the 'gfp' parameter. The only reason to keep it is to
remove flags like __GFP_WAIT. But in its current form, it can only be used
to add flags. So to remove __GFP_WAIT, you'd have to drop it from the
mapping_gfp_mask, which again is stupid as this mask is used by shmem-core
for other allocations, too.

If any driver ever requires that parameter, we can introduce a new helper
that takes the raw 'gfp' parameter. The caller'd be responsible to combine
it with mapping_gfp_mask() in a suitable way. The current
drm_gem_get_pages() helper would then simply use mapping_gfp_mask() and
call the new helper. This is what shmem_read_mapping_pages{_gfp,} does
right now.

Moreover, the gfp-zone flag-usage is not obvious: If you pass a modified
zone, shmem core will WARN() or even BUG(). In other words, the following
must be true for 'gfp' passed to shmem_read_mapping_pages_gfp():
    gfp_zone(mapping_gfp_mask(mapping)) == gfp_zone(gfp)
Add a comment to drm_gem_read_pages() explaining that constraint.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

Add a file to debugfs for each connector to enable modification of the
"force" connector attribute. This allows connectors to be enabled or
disabled for testing and debugging purposes.

v2: Add stricter value checking and clean up debugfs_entry if file
    creation fails in drm_debugfs_connector_add. (David Herrmann)
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
in a few places. I suspect its usage has been spread by copy & paste
rather than anything else.

Let's just remove it for plain ARRAY_SIZE().
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a helper function that allows drivers to statically set the unique
name of the device. This will allow platform and USB drivers to get rid
of their DRM bus implementations and directly use drm_dev_alloc() and
drm_dev_register().
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

For atomic, it will be quite necessary to not need to care so much
about locking order.  And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.

Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
and drm_modeset_acquire_ctx to track acquired locks.

Atomic will use this to keep track of which locks have been acquired
in a transaction.

v1: original
v2: remove a few things not needed until atomic, for now
v3: update for v3 of connection_mutex patch..
v4: squash in docbook
v5: doc tweaks/fixes
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.

v2:
- Polish kerneldoc a bit (Thierry).
- Drop "dev" parameter since it's unecessary.
- Split out i915 changes (Thierry).

Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires vblank interrupt to work during that
time.

Add drm_vblank_on() as a counterpart to drm_vblank_off() which will
re-enabled vblank interrupts if the refcount is already elevated. This
will allow drivers to choose the specific places in the modeset sequence
at which vblank interrupts get disabled and enabled.

Testcase: igt/kms_flip/*-vs-suspend
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add Testcase tag for the igt I've written.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
disable timer per-crtc to avoid this issue.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the last patch to ditch the ->get_name callbacks the last
user is now gone.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.

The exception is usb, which used a generic "USB". Not to harmful with
just one usb driver, but better to use "udl", too.

With that converted we can rip out all the ->get_name implementations.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was only ever used to pretty-print the irq driver name. And on
kms systems due to set_version bonghits we never set up the prettier
name, ever. Which make this a bit pointless.

Also, we can always dig out the driver-instance/irq relationship
through other means, so this isn't that useful. So just rip it out to
simplify the set_version/set_busid insanity a bit.

Also delete the temporary busname from drm_pci_set_busid, it's now
unused.

v2: Rebase on top of the new host1x drm_bus for tegra.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is only used for drm versions 1.0, and kms drivers have never
been there. So we can appropriately restrict this to legacy and hence
pci devices and inline everything.

v2: Make the dummy function actually return something, caught by Wu
Fengguang's 0-day tester.

v3: Fix spelling in comment (Thierry)
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that they're all unused we can get rid of them, including the
dummy version in drm_usb.c.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.

With that we can now also remove drm_dev_to_irq from drm_irq.c.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.

v2: Add the hunk lost in an earlier patch to this one (Thierry).

v3: Fix up the totally fumbled logic in drm_irq_install and use the
local variable consistently. Spotted by both Thierry and Laurent.
Shame on me for failing to properly test the rebase version of this
patch ...

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since really that's all it protects - legacy horror stories in
drm_bufs.c. Since I don't want to waste any more time on this I didn't
bother to actually look at what it protects in there, but it's at
least contained now.

v2: Move the spurious hunk to the right patch (Thierry).

Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.

Unfortunately the vga switcheroo callbacks took this comment at face
value. The problem is that we can't just take the drm_global_mutex
because:
- It would lead to a locking inversion with the driver load/unload
  paths.
- It wouldn't actually protect anything, for that we'd need to wrap
  the entire vga switcheroo code in the drm_global_mutex. And I'm not
  sure whether that would actually solve anything.

What we probably want is a try_to_grab_switcheroo reference kind of
thing which is used in the driver's ->open callback. Then we could
move all that ->can_switch madness into the vga switcheroo core where
it really belongs.

But since that would amount to real work take the easy way out and
just add a comment. It's definitely not going to make anything worse
since doing switcheroo state changes while restarting X just isn't
recommended. Even though the delayed switching code does exactly that.

v2:
- Simplify the ->can_switch implementations more (Thierry)
- Fix comment about the dev->open_count locking (Thierry)

Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v1)
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Completely unused. Hooray, midlayer mistakes that didn't cause work to
undo!

v2: Rebase on top of the recent tegra changes which added a host1x drm
bus.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only used in some legacy pci drivers, and dereferencing the PCI irq is
actually shorter ...

Since this removes all users for drm_dev_to_irq from the tree except
in drm_irq.c, move the inline helper in there. It'll disappear soon,
too.

v2: Polish commit message (Thierry)
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a ums-only ioctl, and we've only ever supported ums (at least
in upstream) on pci devices. So no point in keeping that piece of
legacy logic abstracted within the drm bus driver.

To keep things work without CONFIG_PCI also add a dummy ioctl.

v2: Block the irq_by_busid ioctl for modeset drivers.

v3: Spelling/whitespace polish (Thierry)
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Userspace clients which wish to receive all DRM planes (primary and
cursor planes in addition to the traditional overlay planes) may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES capability.

v2: Hide behind drm.universal_planes module option [suggested by
    Daniel Vetter]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Currently drm_cflush_virt_rage() takes a char* so the caller probably
has to do pointless casting to avoid compiler warnings. Make the
argument void* instead to avoid such issues.

v2: Use void* arithmetic (Chris)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

The master management was previously protected by the drm_device::struct_mutex.
In order to avoid locking order violations in a reworked dropped master
security check in the vmwgfx driver, break it out into a separate master_mutex.
Locking order is master_mutex -> struct_mutex.

Also remove drm_master::blocked since it's not used.

v2: Add an inline comment about what drm_device::master_mutex is protecting.
v3: Remove unneeded struct_mutex locks. Fix error returns in
    drm_setmaster_ioctl().
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

It doesn't appear to be used anywhere.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

Add a drm_is_legacy() helper, constify argument to drm_is_render_client(),
and use / change helpers where appropriate.

v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context.
v3: s/legacy_client/primary_client/
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

Like for render-nodes, there is no point in maintaining the master concept
for control nodes, so set the struct drm_file::master pointer to NULL.

At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
allowed when called through the control node. Previously the caller also
needed to be master.

v2: Adapt to refactoring of ioctl permission check.
v3: Formatting of logical expression. Use drm_is_control_client() instead of
    drm_is_control().
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

This is always DRM_NAME, so we can just make it part of the format
string instead of asking prink to do it for us.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In the logging code, we are currently checking is we need to output in
drm_ut_debug_printk(). This is too late. The problem is that when we write
something like:

    DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
                     connector->base.id,
                     drm_get_connector_name(connector),
                     connector->encoder->base.id,
                     drm_get_encoder_name(connector->encoder));

We start by evaluating the arguments (so call drm_get_connector_name() and
drm_get_connector_name()) before ending up in drm_ut_debug_printk() which will
then does nothing.

This means we execute a lot of instructions (drm_get_connector_name(), in turn,
calls snprintf() for example) to happily discard them in the normal case,
drm.debug=0.

So, let's put the test on drm_debug earlier, in the macros themselves.
Sprinkle an unlikely() as well for good measure.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This macro was trying to use the non existing DRM_UT_MODE debug category
and looks like it should be covered by DRM_LOG_KMS().
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

That comment wasn't super-readable, so I tried to improve it:

- Put the comment before the values it's documenting
- Add a mention to PRIME
- Reword things a bit to be a lighter read
- Add a note about the option to set the debug value at run-time
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Whenever we access minor->device, we are in a minor->kdev->...->fops
callback so the minor->kdev pointer *must* be valid. Thus, simply use
minor->kdev->devt instead of minor->device and remove the redundant field.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of accessing drm_minors_idr directly, this adds a small helper to
hide the internals. This will help us later to remove the drm_global_mutex
requirement for minor-lookup.

Furthermore, this also makes sure that minor->dev is always valid and
takes a reference-count to the device as long as the minor is used in an
open-file. This way, "struct file*"->private_data->dev is guaranteed to be
valid (which it has to, as we cannot reset it).
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Lets not trick ourselves into thinking "drm_device" objects are not
ref-counted. That's just utterly stupid. We manage "drm_minor" objects on
each drm-device and each minor can have an unlimited number of open
handles. Each of these handles has the drm_minor (and thus the drm_device)
as private-data in the file-handle. Therefore, we may not destroy
"drm_device" until all these handles are closed.

It is *not* possible to reset all these pointers atomically and restrict
access to them, and this is *not* how this is done! Instead, we use
ref-counts to make sure the object is valid and not freed.

Note that we currently use "dev->open_count" for that, which is *exactly*
the same as a reference-count, just open coded. So this patch doesn't
change any semantics on DRM devices (well, this patch just introduces the
ref-count, anyway. Follow-up patches will replace open_count by it).

Also note that generic VFS revoke support could allow us to drop this
ref-count again. We could then just synchronously disable any fops->xy()
calls. However, this is not the case, yet, and no such patches are
in sight (and I seriously question the idea of dropping the ref-cnt
again).
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

Use enum for DRM_MINOR_* constants to avoid hard-coding the IDs.
Furthermore, add a DRM_MINOR_CNT so we can perform range-checks in
follow-ups.

This changes the IDs of the minor-types by -1, but they're not used as
indices so this is fine.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This constant is unused, remove it.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These members are all managed by DRM-core, lets group them together so
they're not split across the whole device.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>