* Use addr_of_mut!() instead of &mut for accessing C struct fields

* Add some missing invariant comments

* Use addr_of_mut!() instead of &mut

* Use addr_of_mut!() instead of &mut

* Use addr_of_mut! in more places instead of &mut

* Change name of PlaneType to Type (for consistency with the other type IDs
  we've adde)

* Use addr_of_mut! for accessing fields we were using &mut for.
  I think this is correct after going through some other rfl work?

* Document uses of ManuallyDrop

* Improve safety comments

* Turn all of the encoder type IDs into an enum using a new macro

* Introduce an actual enum for connector types
  I realized we actually could do this fairly easy by using
  #[non_exhaustive], which should future-proof us against new connector
  types being added someday (if that ever happens).

In order to add rust bindings for the various DRM_MODE_CONNECTOR_* type
IDs, we need a way to know the range of defined connector types - since
each type corresponds to an actual array entry in drm_connector_enum_list.

So, let's make this easy to figure out by adding a new
_DRM_MODE_CONNECTOR_COUNT macro that always matches the number of available
connector type IDs. Also, use that macro to define the size of
drm_connector_enum_list to ensure that builds fail if someone attempts to
add a new entry to drm_connector_enum_list without updating this macro.

Signed-off-by: Lyude Paul <lyude@redhat.com>

We're going to be calling some methods from AllocImpl directly in
Registration::new() - which means that the rust compiler needs to know that
our associated AllocImpl trait uses us as a Driver trait. Otherwise, it'll
complain about a missing trait bound.

The simplest way to do this is to just add this as a trait bound for the
associated Driver::Object trait.

Signed-off-by: Lyude Paul <lyude@redhat.com>

gotta poke andreas about this one! looks like we forgot to actually expose
this type

same for irq spinlocks. This will get dropped in the future since it's no
longer the solution that we're going to be going for upstream, but it is
taking forever for simple patches to be merged :(.

Signed-off-by: Lyude Paul <lyude@redhat.com>

A simple helper alias for code that needs to deal with Guard types returned
from SpinLocks.

Signed-off-by: Lyude Paul <lyude@redhat.com>

A simple helper alias for code that needs to deal with Guard types returned
from Mutexes.

Signed-off-by: Lyude Paul <lyude@redhat.com>

Now that we've added all of the bits that we need for the KMS API, it's
time to introduce rvkms! This is a port of the VKMS driver to rust, with
the intent of acting as an example usecase of the KMS bindings that we've
come up with so far in preparation for writing a display driver for nova.

Currently RVKMS is an extremely bear bones driver - it only registers a
device and emulates vblanking, but it exercises a good portion of the API
that we've introduced so far! Eventually I hope to introduce CRC generation
and maybe writeback connectors like.

Signed-off-by: Lyude Paul <lyude@redhat.com>

---
V3:
* Replace platform device usage with faux device

A quick note: this is one of my favorite bindings so far :). It sounds way
overly complicated, but so far actually writing implementations of this in
rust has been a breeze.

Anyway: RVKMS has a slightly different atomic_commit_tail than normal,
which means we need to write up some bindings for atomic_commit_tail. This
is a lot more interesting then it might seem on the surface as implementing
atomic_commit_tail incorrectly could result in UB. And in general, DRM has
up until now relied entirely on the programmer to do this correctly through
implicit ordering requirements.

In the universe of rust though, we want no UB at all! To ensure this, we
need to make sure that all atomic commit callbacks follow all of these
requirements:

* Disable/enable modeset commits must happen exactly once
* A disable modeset must be committed for a resource before an enable
  modeset may be committed for a resource
* Plane updates must happen exactly once
* drm_atomic_commit_hw_done() must be called exactly once, and only after
  all commits have been completed.
* The state may not be mutated after drm_atomic_commit_hw_done() is called
* Access to the prior atomic states are revoked after
  drm_atomic_commit_hw_done() is called (and our "new" states become "old"
  states)

To handle this, we introduce a number of new objects and types:
tokens:

* AtomicCommitTail
  Main object for controlling the commit_tail process
  * ModesetsReadyToken
    A single use token indicating that no modesets have been committed with
    the AtomicCommitTail yet
  * commit_modeset_disables() -> DisablesCommittedToken
    This function consumes the ModesetsReadyToken, commits modeset
    disables, and then returns a DisablesCommittedToken
  * commit_modeset_enables() -> EnablesCommittedToken
    This function consumes a DisablesCommittedToken, commits modeset
    enables, and then returns a EnablesCommittedToken
    EnablesCommittedToken - enforcing the disables -> enables order.
  * commit_planes() -> PlaneUpdatesCommittedToken
    Consumes a PlaneUpdatesReadyToken and returns a
    PlaneUpdatesCommittedToken.
  * commit_hw_done() -> CommittedAtomicState
    Revokes access to the AtomicCommitTailObject, and consumes both the
    EnablesCommittedToken and PlaneUpdatesCommitted tokens. This ensures
    that all modesets and plane updates have occurred exactly once.
* CommittedAtomicState - main object for controlling the atomic_commit_tail
  after the state has been swapped in. This must be returned from the
  atomic_commit_tail function to prove that all of the required commits
  have occurred.

Signed-off-by: Lyude Paul <lyude@redhat.com>

---

TODO:

* Currently this solution wouldn't be sufficient for drivers that need
  precise control over the order of each individual modeset or plane
  update. However, this should be very easy to add.
* Figure out something better for enforcing the plane cleanup then what we
  have right now (e.g. cleaning up planes in the destructor for
  CommittedAtomicState).
* Add iterator functions that take mutable references to the atomic state
  objects here. This will prevent functions like commit_modeset_disables()
  from being called while a state borrow is taken out, while still allowing
  easy access to the contents of the atomic state at any portion of the
  atomic commit tail.
* Actually add some macros for generating bitmasks like we do with
  PlaneCommitFlags - right now we just do this by hand.

This commit adds bindings for implementing vblank support for a driver's
CRTCs. These bindings are optional, to account for the fact that not all
drivers have dedicated hardware vblanks.

In order to accomplish this, we introduce the VblankSupport trait which can
be implemented on DriverCrtc by drivers which support vblanks. This works
in the same way as the main Kms trait - drivers which don't support
hardware vblanks can simply pass PhantomData<Self> to the associated type
on DriverCrtc. If a driver chooses to implement VblankSupport, VblankImpl
will be implemented by DRM automatically - and can be passed to the
VblankImpl associated type on DriverCrtc.

Additionally, we gate methods which only apply to vblank-supporting drivers
by introducing a VblankDriverCrtc trait that is automatically implemented
by DRM for CRTC drivers implementing VblankSupport. This works basically in
the same way as Kms and KmsDriver, but for CRTCs.

Signed-off-by: Lyude Paul <lyude@redhat.com>

---

Notes:

* One thing to keep in mind: this trait is implemented on the CRTC as
  opposed to the KMS driver due to the possibility that a driver may have
  multiple different types of CRTCs. As a result, it's not impossible that
  there could potentially be differences in each type's vblank hardware
  implementation. In theory this could lead to a driver mistakenly only
  implementing VblankSupport for some CRTCs and not others, which isn't
  really defined behavior in DRM. As such, one of the dependencies in the
  branch for this patch series preview is a fix to ensure that DRM
  disallows registering drivers that make this mistake.

V3:
* Update to the latest SpinlockIrq changes
* Fix typo on get_vblank_timestamp()
* Break statements in vblank_crtc() up a bit
* Add comments around all uses of ManuallyDrop
* Improve SAFETY comments
* Make some unsafe scopes smaller

A binding for checking drm_device.num_crtcs. We'll need this in a moment
for vblank support, since setting it up requires knowing the number of
CRTCs that a driver has initialized.

Signed-off-by: Lyude Paul <lyude@redhat.com>

This is just a crate-private helper to use Lock::from_raw() to provide an
immutable reference to the DRM event_lock, so that it can be used like a
normal rust spinlock. We'll need this for adding vblank related bindings.

Signed-off-by: Lyude Paul <lyude@redhat.com>