I've tested vblank events to at least make sure we're firing them off from
the driver, and am currently in the process of fixing one remaining vblank
ref leak. It -should- be fixed now, but I have yet to actually run this
code in my VM and am currently pushing this so there's something to look at
for my team status report :).

Things to split out of this commit:
* Random misc. cleanups
* One safety addition to the C side of DRM (specifically, if one CRTC
  supports vblanks it does not make sense for others to not have things
  like enable_vblank/disable_vblank not implemented - so check for that)
* More hrtimer WIP
* Some additions to Ktime

A few of the APIs I've been writing bindings for (KMS in particular) rely
on the user manually acquiring specific locks before calling certain
functions. At the moment though, the only way of acquiring these locks in
bindings is to simply call the C locking functions directly - since said
locks are not acquired on the rust side of things.

However - if we add `#[repr(C)]` to `Lock<T, B>`, then given `T` is a ZST -
`Lock<T, B>` becomes equivalent in data layout to its inner `B::State`
type. Since locks in C don't have data explicitly associated with them
anyway, we can take advantage of this to add a `Lock::from_raw()` function
that can translate a raw pointer to `B::State` into its proper `Lock<T, B>`
equivalent. This lets us simply acquire a reference to the lock in question
and work with it like it was initialized on the rust side of things,
allowing us to use less unsafe code to implement bindings with lock
requirements.

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

A variant of SpinLock that is expected to be used in noirq contexts, and
thus requires that the user provide an kernel::irq::IrqDisabled to prove
they are in such a context upon lock acquisition. This is the rust
equivalent of spin_lock_irqsave()/spin_lock_irqrestore().

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

---

V2:
* s/IrqSpinLock/SpinLockIrq/
* Implement `lock::Backend` now that we have `Context`
* Add missing periods
* Make sure rustdoc examples compile correctly
* Add documentation suggestions

Now that we've introduced an `IrqDisabled` token for marking contexts in
which IRQs are disabled, we need a way to be able to pass it to locks that
require that IRQs are disabled. In order to continue using the
`lock::Backend` type instead of inventing our own thing, we accomplish this
by adding the associated Context type, along with a `lock_with()` function
that can accept a Context when acquiring a lock. To allow current users of
context-less locks to keep using the normal `lock()` method, we take an
example from Wedson Almeida Filho's work and add a `where T<'a>: Default`
bound to `lock()` so that it can only be called on lock types where the
context is simply a placeholder value, then re-implement it through the new
`lock_with()` function.

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

---

V3:
* Use explicit lifetimes in lock_with() to ensure self and _context have
  the same lifetime (Benno)
* Use () for locks that don't need a Context instead of PhantomData (Benno)

This introduces a module for dealing with interrupt-disabled contexts,
including the ability to enable and disable interrupts
(with_irqs_disabled()) - along with the ability to annotate functions as
expecting that IRQs are already disabled on the local CPU.

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

---

V2:
* Actually make it so that we check whether or not we have interrupts
  disabled with debug assertions
* Fix issues in the documentation (added suggestions, missing periods, made
  sure that all rustdoc examples compile properly)
* Pass IrqDisabled by value, not reference
* Ensure that IrqDisabled is !Send and !Sync using
  PhantomData<(&'a (), *mut ())>
* Add all of the suggested derives from Benno Lossin

V3:
* Use `impl` for FnOnce bounds in with_irqs_disabled()
* Use higher-ranked trait bounds for the lifetime of with_irqs_disabled()
* Wording changes in the documentation for the module itself

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.

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

This reverts commit 23070e00.

Unsure if this should be in the TimerCallbackContext struct - we'll see
what Andreas thinks

* I totally forgot that we actually need to both add a callback for
  handling cleaning up a timer that didn't execute as a result of being
  cancelled

Just a type alias to represent SpinLockGuards, since we will be storing
these in a struct.

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

A simple function to turn the provided value in nanoseconds into a Ktime
value. We allow any type which implements Into<bindings::ktime_t>, which
resolves to Into<i64>.

This is useful for some of the older DRM APIs that never got moved to Ktime

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

This allows us to store hrtimers in the driver's private CRTC data, which
we can use in rvkms for emulating vblanks.

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

Using the rest of the bindings we've just added, add a binding for
hrtimer_forward_now().

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

This is just a binding for hrtimer_cb_get_time() - which we'll be using in
a moment for implementing a binding for hrtimer_forward_now().

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

With Linux's hrtimer API, certain functions require we either acquire
proper locking to call specific methods - or that we call said methods from
the context of the timer callback. hrtimer_forward() is one of these
functions, so we start by adding a new TimerCallbackContext type which
provides a way of calling these methods that is inaccessible outside of
hrtimer callbacks.

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

A binding for hrtimer_cancel(). Additionally, begin using this safe wrapper
in our PinnedDrop implementation.

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

While working on rvkms, I noticed that there's no code that actually uses
the drm_pending_vblank_event that's embedded in vkms_output. So, just drop
the member from the struct.

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

Andreas Hindborg authored 8 months ago and Lyude Paul committed 8 months ago

one timer can be embedded in a Rust struct.

The hrtimer Rust API is based on the intrusive style pattern introduced by the
Rust workqueue API.

Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>

It turns out that if you happen to have a kernel config where
CONFIG_DRM_PANIC is disabled and spinlock debugging is enabled, along with
KMS being enabled - we'll end up trying to acquire an uninitialized
spin_lock with drm_panic_lock() when we try to do a commit:

  rvkms rvkms.0: [drm:drm_atomic_commit] committing 0000000068d2ade1
  INFO: trying to register non-static key.
  The code is fine but needs lockdep annotation, or maybe
  you didn't initialize this object before use?
  turning off the locking correctness validator.
  CPU: 4 PID: 1347 Comm: modprobe Not tainted 6.10.0-rc1Lyude-Test+ #272
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240524-3.fc40 05/24/2024
  Call Trace:
   <TASK>
   dump_stack_lvl+0x77/0xa0
   assign_lock_key+0x114/0x120
   register_lock_class+0xa8/0x2c0
   __lock_acquire+0x7d/0x2bd0
   ? __vmap_pages_range_noflush+0x3a8/0x550
   ? drm_atomic_helper_swap_state+0x2ad/0x3a0
   lock_acquire+0xec/0x290
   ? drm_atomic_helper_swap_state+0x2ad/0x3a0
   ? lock_release+0xee/0x310
   _raw_spin_lock_irqsave+0x4e/0x70
   ? drm_atomic_helper_swap_state+0x2ad/0x3a0
   drm_atomic_helper_swap_state+0x2ad/0x3a0
   drm_atomic_helper_commit+0xb1/0x270
   drm_atomic_commit+0xaf/0xe0
   ? __pfx___drm_printfn_info+0x10/0x10
   drm_client_modeset_commit_atomic+0x1a1/0x250
   drm_client_modeset_commit_locked+0x4b/0x180
   drm_client_modeset_commit+0x27/0x50
   __drm_fb_helper_restore_fbdev_mode_unlocked+0x76/0x90
   drm_fb_helper_set_par+0x38/0x40
   fbcon_init+0x3c4/0x690
   visual_init+0xc0/0x120
   do_bind_con_driver+0x409/0x4c0
   do_take_over_console+0x233/0x280
   do_fb_registered+0x11f/0x210
   fbcon_fb_registered+0x2c/0x60
   register_framebuffer+0x248/0x2a0
   __drm_fb_helper_initial_config_and_unlock+0x58a/0x720
   drm_fbdev_generic_client_hotplug+0x6e/0xb0
   drm_client_register+0x76/0xc0
   _RNvXs_CsHeezP08sTT_5rvkmsNtB4_5RvkmsNtNtCs1cdwasc6FUb_6kernel8platform6Driver5probe+0xed2/0x1060 [rvkms]
   ? _RNvMs_NtCs1cdwasc6FUb_6kernel8platformINtB4_7AdapterNtCsHeezP08sTT_5rvkms5RvkmsE14probe_callbackBQ_+0x2b/0x70 [rvkms]
   ? acpi_dev_pm_attach+0x25/0x110
   ? platform_probe+0x6a/0xa0
   ? really_probe+0x10b/0x400
   ? __driver_probe_device+0x7c/0x140
   ? driver_probe_device+0x22/0x1b0
   ? __device_attach_driver+0x13a/0x1c0
   ? __pfx___device_attach_driver+0x10/0x10
   ? bus_for_each_drv+0x114/0x170
   ? __device_attach+0xd6/0x1b0
   ? bus_probe_device+0x9e/0x120
   ? device_add+0x288/0x4b0
   ? platform_device_add+0x75/0x230
   ? platform_device_register_full+0x141/0x180
   ? rust_helper_platform_device_register_simple+0x85/0xb0
   ? _RNvMs2_NtCs1cdwasc6FUb_6kernel8platformNtB5_6Device13create_simple+0x1d/0x60
   ? _RNvXs0_CsHeezP08sTT_5rvkmsNtB5_5RvkmsNtCs1cdwasc6FUb_6kernel6Module4init+0x11e/0x160 [rvkms]
   ? 0xffffffffc083f000
   ? init_module+0x20/0x1000 [rvkms]
   ? kernfs_xattr_get+0x3e/0x80
   ? do_one_initcall+0x148/0x3f0
   ? __lock_acquire+0x5ef/0x2bd0
   ? __lock_acquire+0x5ef/0x2bd0
   ? __lock_acquire+0x5ef/0x2bd0
   ? put_cpu_partial+0x51/0x1d0
   ? lock_acquire+0xec/0x290
   ? put_cpu_partial+0x51/0x1d0
   ? lock_release+0xee/0x310
   ? put_cpu_partial+0x51/0x1d0
   ? fs_reclaim_acquire+0x69/0xf0
   ? lock_acquire+0xec/0x290
   ? fs_reclaim_acquire+0x69/0xf0
   ? kfree+0x22f/0x340
   ? lock_release+0xee/0x310
   ? kmalloc_trace_noprof+0x48/0x340
   ? do_init_module+0x22/0x240
   ? kmalloc_trace_noprof+0x155/0x340
   ? do_init_module+0x60/0x240
   ? __se_sys_finit_module+0x2e0/0x3f0
   ? do_syscall_64+0xa4/0x180
   ? syscall_exit_to_user_mode+0x108/0x140
   ? do_syscall_64+0xb0/0x180
   ? vma_end_read+0xd0/0xe0
   ? do_user_addr_fault+0x309/0x640
   ? clear_bhb_loop+0x45/0xa0
   ? clear_bhb_loop+0x45/0xa0
   ? clear_bhb_loop+0x45/0xa0
   ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
   </TASK>

Fix this by stubbing these macros out when this config option isn't
enabled, along with fixing the unused variable warning that introduces.

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

Sima pointed out that drm_crtc_state violates some of the guarantees that
other atomic states have, in that the structure can be mutated even after
being swapped in. As a result, we need to update our bindings to not assume
that this structure follows rust's data aliasing rules like the rest of the
KMS atomic states.

Now that we've added all of the bits that we need for the KMS API, it's
time to Bring The Beef and introduce RVKMS!

TODO: write something more here I guess?

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

Just a simple binding for retrieving the name of the device through
dev_name().

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

TODO:
* The idea for this came from Maíra originally, and they should probably be
  the commit author (we'll fix that before final submission because credit
  is important :3, right now it's just a bit easier to rewrite the commit)

A binding for retrieving the current rotation of a DRM plane state.

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

Just a binding for drm_simplify_rotation(). We add this in a new module
blend.rs in order to match the layout of the C side of things.

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

Just add some short-hand aliases to the raw bindings, since that's
basically all we need. We put this in a new mode.rs module to match the
layout of the C side of KMS.

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

Bindings for returning the src and dst rectangles for an atomic plane
state.

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

This is just a binding around drm_mode_config_reset(), which should be
called during initialization of a modesetting driver if it doesn't
read-back hardware state.

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

Since RVKMS uses drm_shadow_plane_state instead of the normal
drm_plane_state, let's add bindings to allow drivers to use this using the
PlaneStateHelper trait that we introduced before.

Of course, all of the normal methods available to DRM planes are also
available on shadow planes through the use of AsRawPlaneState and friends.

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

TODO:
* Make sure that documentation is consistent and finished

Add optional trait methods for DRM's prepare_fb() and cleanup_fb()
callbacks now that we have proper Framebuffer bindings. As well, introduce
a new PlaneState mutator: PlaneStateMutator. The purpose of this mutator
type is for callbacks where we want the implementor to be able to modify
the atomic plane state, without providing access to the rest of the atomic
state.

TODO:
* Write documentation

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

Returns the Framebuffer currently assigned in an atomic plane state.

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

We're about to add some FB related callbacks to planes now, so let's
introduce our bindings for Framebuffer objects. Just like Connectors, these
use RcModeObject.

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

A mandatory trait method used for implementing DRM's atomic plane update
callback. This is currently only mandatory because with our current
bindings, DRM will crash without this.

TODO: See if we can fix that and make it only mandatory in certain
situations.

Add a binding for DRM's plane state atomic check helper.

TODO:
* Finish up documentation (we need to document parameters too! I think?)

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

Add a binding for retrieving an opaque reference to the CRTC currently set
for an atomic plane state.

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

Optional trait method for implementing a plane's atomic_check().

TODO:
* Documentation
* Figure out if we can make this non-mandatory?

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

An optional trait method for implementing a CRTC's atomic state check.

TODO: Write documentation

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