Re: [PATCH v2 1/8] rust: drm: ioctl: Add DRM ioctl abstraction
On Wed, Jun 19, 2024 at 01:31:37AM +0200, Danilo Krummrich wrote:
> From: Asahi Lina
>
> DRM drivers need to be able to declare which driver-specific ioctls they
> support. Add an abstraction implementing the required types and a helper
> macro to generate the ioctl definition inside the DRM driver.
>
> Note that this macro is not usable until further bits of the abstraction
> are in place (but it will not fail to compile on its own, if not called).
>
> Signed-off-by: Asahi Lina
> Signed-off-by: Danilo Krummrich
Aside from the fixme commments in here I also had a bit a wishlist/ideas
compilation of my own:
https://lore.kernel.org/dri-devel/ZDfKLjKOfDHkEc1V@phenom.ffwll.local/#t
Not sure where/how we want to record all these, and when we should try to
fix them?
-Sima
> ---
> rust/bindings/bindings_helper.h | 1 +
> rust/kernel/drm/ioctl.rs| 153
> rust/kernel/drm/mod.rs | 5 ++
> rust/kernel/lib.rs | 2 +
> rust/uapi/uapi_helper.h | 1 +
> 5 files changed, 162 insertions(+)
> create mode 100644 rust/kernel/drm/ioctl.rs
> create mode 100644 rust/kernel/drm/mod.rs
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 30ad2a0e22d7..ed25b686748e 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,6 +6,7 @@
> * Sorted alphabetically.
> */
>
> +#include
> #include
> #include
> #include
> diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> new file mode 100644
> index ..09ca7a8e7583
> --- /dev/null
> +++ b/rust/kernel/drm/ioctl.rs
> @@ -0,0 +1,153 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +#![allow(non_snake_case)]
> +
> +//! DRM IOCTL definitions.
> +//!
> +//! C header:
> [`include/linux/drm/drm_ioctl.h`](srctree/include/linux/drm/drm_ioctl.h)
> +
> +use crate::ioctl;
> +
> +const BASE: u32 = uapi::DRM_IOCTL_BASE as u32;
> +
> +/// Construct a DRM ioctl number with no argument.
> +#[inline(always)]
> +pub const fn IO(nr: u32) -> u32 {
> +ioctl::_IO(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-only argument.
> +#[inline(always)]
> +pub const fn IOR(nr: u32) -> u32 {
> +ioctl::_IOR::(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a write-only argument.
> +#[inline(always)]
> +pub const fn IOW(nr: u32) -> u32 {
> +ioctl::_IOW::(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-write argument.
> +#[inline(always)]
> +pub const fn IOWR(nr: u32) -> u32 {
> +ioctl::_IOWR::(BASE, nr)
> +}
> +
> +/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro to
> construct them.
> +pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
> +
> +/// This is for ioctl which are used for rendering, and require that the
> file descriptor is either
> +/// for a render node, or if it’s a legacy/primary node, then it must be
> authenticated.
> +pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
> +
> +/// This must be set for any ioctl which can change the modeset or display
> state. Userspace must
> +/// call the ioctl through a primary node, while it is the active master.
> +///
> +/// Note that read-only modeset ioctl can also be called by unauthenticated
> clients, or when a
> +/// master is not the currently active one.
> +pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
> +
> +/// Anything that could potentially wreak a master file descriptor needs to
> have this flag set.
> +///
> +/// Current that’s only for the SETMASTER and DROPMASTER ioctl, which e.g.
> logind can call to
> +/// force a non-behaving master (display compositor) into compliance.
> +///
> +/// This is equivalent to callers with the SYSADMIN capability.
> +pub const ROOT_ONLY: u32 = bindings::drm_ioctl_flags_DRM_ROOT_ONLY;
> +
> +/// This is used for all ioctl needed for rendering only, for drivers which
> support render nodes.
> +/// This should be all new render drivers, and hence it should be always set
> for any ioctl with
> +/// `AUTH` set. Note though that read-only query ioctl might have this set,
> but have not set
> +/// DRM_AUTH because they do not require authentication.
> +pub const RENDER_ALLOW: u32 = bindings::drm_ioctl_flags_DRM_RENDER_ALLOW;
> +
> +/// Internal structures used by the `declare_drm_ioctls!{}` macro. Do not
> use directly.
> +#[doc(hidden)]
> +pub mod internal {
> +pub use bindings::drm_device;
> +pub use bindings::drm_file;
> +pub use bindings::drm_ioctl_desc;
> +}
> +
> +/// Declare the DRM ioctls for a driver.
> +///
> +/// Each entry in the list should have the form:
> +///
> +/// `(ioctl_number, argument_type, flags, user_callback),`
> +///
> +/// `argument_type` is the type name within the `bindings` crate.
> +/// `user_callback` should have the following prototype:
> +///
> +/// ```ignore
> +/// fn foo(device: &kernel::drm::device::Device,
> +///data: &mut bindings::argume
Re: [PATCH v2 0/8] DRM Rust abstractions and Nova
On Wed, Jun 19, 2024 at 01:31:36AM +0200, Danilo Krummrich wrote: > This patch series implements some basic DRM Rust abstractions and a stub > implementation of the Nova GPU driver. > > Nova is intended to be developed upstream, starting out with just a stub > driver > to lift some initial required infrastructure upstream. A more detailed > explanation can be found in [1]. > > This patch series is based on the "Device / Driver and PCI Rust abstractions" > series [2]. > > The DRM bits can also be found in [3] and the Nova bits in [4]. > > Changes in v2: > == > - split up the DRM device / driver abstractions in three separate commits > - separate `struct drm_device` abstraction in a separte source file more > cleanly > - switch `struct drm_driver` and `struct file_operations` to 'static const' > allocations > - implement `Registration::new_foreign_owned` (using `Devres`), such that we > don't need to keep the `Registration` alive on the Rust side, but > automatically revoke it on device unbind > - add missing DRM driver features (Rob) > - use `module_pci_driver!` macro in Nova > - use a const sized `pci::Bar` in Nova > - increase the total amount of Documentation, rephrase some safety comments > and > commit messages for less ambiguity > - fix compilation issues with some documentation example > > [1] https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/T/#u > [2] Reply to this mail titled "Device / Driver and PCI Rust abstractions". > [3] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm > [4] https://gitlab.freedesktop.org/drm/nova/-/tree/nova-next Ok finally stopped dragging my feet on this, went through my old comments, looked at stuff again, and wrote some replies. I think all but the question around type safety for drm_driver->features can be sorted out post-merge, when we have a driver that needs it. The feature flags stuff I think essentially makes the current abstraction unsafe, and you can blow up when constructing a new drm::Device instance if you're creative enough I think. Cheers, Sima > > Asahi Lina (4): > rust: drm: ioctl: Add DRM ioctl abstraction > rust: Add a Sealed trait > rust: drm: file: Add File abstraction > rust: drm: gem: Add GEM object abstraction > > Danilo Krummrich (4): > rust: drm: add driver abstractions > rust: drm: add device abstraction > rust: drm: add DRM driver registration > nova: add initial driver stub > > MAINTAINERS | 10 + > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/nova/Kconfig| 12 + > drivers/gpu/drm/nova/Makefile | 3 + > drivers/gpu/drm/nova/driver.rs | 85 +++ > drivers/gpu/drm/nova/file.rs| 70 ++ > drivers/gpu/drm/nova/gem.rs | 50 > drivers/gpu/drm/nova/gpu.rs | 173 ++ > drivers/gpu/drm/nova/nova.rs| 18 ++ > include/uapi/drm/nova_drm.h | 101 > rust/bindings/bindings_helper.h | 5 + > rust/helpers.c | 23 ++ > rust/kernel/drm/device.rs | 182 ++ > rust/kernel/drm/drv.rs | 199 > rust/kernel/drm/file.rs | 116 + > rust/kernel/drm/gem/mod.rs | 409 > rust/kernel/drm/ioctl.rs| 153 > rust/kernel/drm/mod.rs | 9 + > rust/kernel/lib.rs | 7 + > rust/uapi/uapi_helper.h | 2 + > 21 files changed, 1630 insertions(+) > create mode 100644 drivers/gpu/drm/nova/Kconfig > create mode 100644 drivers/gpu/drm/nova/Makefile > create mode 100644 drivers/gpu/drm/nova/driver.rs > create mode 100644 drivers/gpu/drm/nova/file.rs > create mode 100644 drivers/gpu/drm/nova/gem.rs > create mode 100644 drivers/gpu/drm/nova/gpu.rs > create mode 100644 drivers/gpu/drm/nova/nova.rs > create mode 100644 include/uapi/drm/nova_drm.h > create mode 100644 rust/kernel/drm/device.rs > create mode 100644 rust/kernel/drm/drv.rs > create mode 100644 rust/kernel/drm/file.rs > create mode 100644 rust/kernel/drm/gem/mod.rs > create mode 100644 rust/kernel/drm/ioctl.rs > create mode 100644 rust/kernel/drm/mod.rs > > > base-commit: 6646240d29b11de3177f71ff777d0ae683c32623 > -- > 2.45.1 > -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 3/8] rust: drm: add driver abstractions
On Wed, Jun 19, 2024 at 01:31:39AM +0200, Danilo Krummrich wrote:
> Implement the DRM driver abstractions.
>
> The `Driver` trait provides the interface to the actual driver to fill
> in the driver specific data, such as the `DriverInfo`, driver features
> and IOCTLs.
>
> Co-developed-by: Asahi Lina
> Signed-off-by: Asahi Lina
> Signed-off-by: Danilo Krummrich
> ---
> rust/bindings/bindings_helper.h | 1 +
> rust/kernel/drm/drv.rs | 141
> rust/kernel/drm/mod.rs | 1 +
> 3 files changed, 143 insertions(+)
> create mode 100644 rust/kernel/drm/drv.rs
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index ed25b686748e..dc19cb789536 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,6 +6,7 @@
> * Sorted alphabetically.
> */
>
> +#include
> #include
> #include
> #include
> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> new file mode 100644
> index ..cd594a32f9e4
> --- /dev/null
> +++ b/rust/kernel/drm/drv.rs
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM driver core.
> +//!
> +//! C header:
> [`include/linux/drm/drm_drv.h`](srctree/include/linux/drm/drm_drv.h)
> +
> +use crate::{bindings, drm, private::Sealed, str::CStr,
> types::ForeignOwnable};
> +use macros::vtable;
> +
> +/// Driver use the GEM memory manager. This should be set for all modern
> drivers.
> +pub const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
> +/// Driver supports mode setting interfaces (KMS).
> +pub const FEAT_MODESET: u32 = bindings::drm_driver_feature_DRIVER_MODESET;
> +/// Driver supports dedicated render nodes.
> +pub const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
> +/// Driver supports the full atomic modesetting userspace API.
> +///
> +/// Drivers which only use atomic internally, but do not support the full
> userspace API (e.g. not
> +/// all properties converted to atomic, or multi-plane updates are not
> guaranteed to be tear-free)
> +/// should not set this flag.
> +pub const FEAT_ATOMIC: u32 = bindings::drm_driver_feature_DRIVER_ATOMIC;
> +/// Driver supports DRM sync objects for explicit synchronization of command
> submission.
> +pub const FEAT_SYNCOBJ: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ;
> +/// Driver supports the timeline flavor of DRM sync objects for explicit
> synchronization of command
> +/// submission.
> +pub const FEAT_SYNCOBJ_TIMELINE: u32 =
> bindings::drm_driver_feature_DRIVER_SYNCOBJ_TIMELINE;
> +/// Driver supports compute acceleration devices. This flag is mutually
> exclusive with `FEAT_RENDER`
> +/// and `FEAT_MODESET`. Devices that support both graphics and compute
> acceleration should be
> +/// handled by two drivers that are connected using auxiliary bus.
> +pub const FEAT_COMPUTE_ACCEL: u32 =
> bindings::drm_driver_feature_DRIVER_COMPUTE_ACCEL;
> +/// Driver supports user defined GPU VA bindings for GEM objects.
> +pub const FEAT_GEM_GPUVA: u32 =
> bindings::drm_driver_feature_DRIVER_GEM_GPUVA;
> +/// Driver supports and requires cursor hotspot information in the cursor
> plane (e.g. cursor plane
> +/// has to actually track the mouse cursor and the clients are required to
> set hotspot in order for
> +/// the cursor planes to work correctly).
> +pub const FEAT_CURSOR_HOTSPOT: u32 =
> bindings::drm_driver_feature_DRIVER_CURSOR_HOTSPOT;
> +
> +/// Information data for a DRM Driver.
> +pub struct DriverInfo {
> +/// Driver major version.
> +pub major: i32,
> +/// Driver minor version.
> +pub minor: i32,
> +/// Driver patchlevel version.
> +pub patchlevel: i32,
> +/// Driver name.
> +pub name: &'static CStr,
> +/// Driver description.
> +pub desc: &'static CStr,
> +/// Driver date.
> +pub date: &'static CStr,
> +}
> +
> +/// Internal memory management operation set, normally created by memory
> managers (e.g. GEM).
> +///
> +/// See `kernel::drm::gem` and `kernel::drm::gem::shmem`.
> +pub struct AllocOps {
> +pub(crate) gem_create_object: Option<
> +unsafe extern "C" fn(
> +dev: *mut bindings::drm_device,
> +size: usize,
> +) -> *mut bindings::drm_gem_object,
> +>,
> +pub(crate) prime_handle_to_fd: Option<
> +unsafe extern "C" fn(
> +dev: *mut bindings::drm_device,
> +file_priv: *mut bindings::drm_file,
> +handle: u32,
> +flags: u32,
> +prime_fd: *mut core::ffi::c_int,
> +) -> core::ffi::c_int,
> +>,
> +pub(crate) prime_fd_to_handle: Option<
> +unsafe extern "C" fn(
> +dev: *mut bindings::drm_device,
> +file_priv: *mut bindings::drm_file,
> +prime_fd: core::ffi::c_int,
> +handle: *mut u32,
> +) -> core::ffi::c_int,
> +>,
> +pub(crate) gem_prime_import: Option<
> +un
Re: [PATCH v2 1/9] drm: Do delayed switcheroo in drm_lastclose()
On Mon, Aug 12, 2024 at 12:41:39PM +0200, Thomas Zimmermann wrote: > Hi > > Am 12.08.24 um 12:18 schrieb Daniel Vetter: > > On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote: > > > On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > > > > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > > > > their lastclose callbacks. Call it from drm_lastclose(), so that the > > > > driver functions can finally be removed. Only PCI devices with enabled > > > > switcheroo do the delayed switching. The call has no effect on other > > > > hardware. > > > > > > > > v2: > > > > - move change to drm_lastclose() (Sima) > > > > - update docs for vga_switcheroo_process_delayed_switch() > > > > > > > > Signed-off-by: Thomas Zimmermann > > > A bit an aside: The entire vgaswitcheroo code is still a midlayer mess, > > > where the locking is at the wrong layers resulting in the can_switch check > > > potentially being racy. But that's a different can of worms. > > Ok I got a bit annoyed about this mess again, and I think I have a > > reasonable idea for how to address it. Not sure why this took a decade, > > and definitely only pick this up if you're really bored. > > No, definitely not. :) I don't think I have hardware for testing > vga_switcheroo. Does this still exist? It seemed to be a thing of the 2000s. Yeah good chances the old style switcheroo doesn't have many, if any users left ... -Sima > > Best regards > Thomas > > > > > - We add a new vga_switcheroo_client_tryget, which checks the current > >state, and if it's on, increments a newly added refcount (which vgw > >switheroo maintains). Otherwise it fails. Drivers call this from their > >drm_driver->open hook. This check also allows us to drop the > >layer-violating checks in drm_open_helper for drm_dev->dev_power_state. > > > > - That refcount is dropped with vga_switcheroo_client_put, called from > >drm_driver->close. If the refcount drops to 0 this function also does > >delayed switch processing. > > > > - All the can_switch callbacks get removed and instead the vgwswr code > >directly consults its own refount. > > > > With this we don't have locking inversions anymore, and the old vgw > > switcheroo code works a lot more like the new mode based on runtime pm and > > power domains. > > > > With a bit more shuffling I think we can also ditch > > drm_driver->dev_power_state: > > > > - There's one in the intel backlight code, which is annoying, since it's > >wants to know whether the current callchain is from a vga switcheroo > >state change. But doable with a little helper. > > > > - Most others just want a vga_switcheroo_client_is_off() helper, which > >should be easy. Some are even entirely redundant, at least from a cursor > >callchain check. There's no races for these because they only matter > >during system suspend, since you should not mix both runtime and classic > >vgaswitcheroo logic. We might want some checks for that in that new > >helper ... > > > > - The one in the fbdev code is annoying, because it's another race. > >Ideally instead of that check it needs a call to > >vga_switcheroo_client_tryget/put just around the call to restore modes > >(we do not want fbdev to block state switches), but that probably means > >wiring a new callback through drm_client to drivers. > > > > - Might have missed a special case ... > > > > Anyway, I got nerdsniped, had an idea, figured best to type it up. Maybe > > we want to add a link to this to todo.rst, I think we have a vgaswitcheroo > > entry already. > > > > Cheers, Sima > > > > > > > Reviewed-by: Daniel Vetter > > > > > > > --- > > > > drivers/gpu/drm/drm_file.c | 4 > > > > drivers/gpu/vga/vga_switcheroo.c | 3 +-- > > > > 2 files changed, 5 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > > > > index 714e42b05108..513bef816ae9 100644 > > > > --- a/drivers/gpu/drm/drm_file.c > > > > +++ b/drivers/gpu/drm/drm_file.c > > > > @@ -38,6 +38,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include >
Re: [PATCH v2 1/9] drm: Do delayed switcheroo in drm_lastclose()
On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote: > On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > > their lastclose callbacks. Call it from drm_lastclose(), so that the > > driver functions can finally be removed. Only PCI devices with enabled > > switcheroo do the delayed switching. The call has no effect on other > > hardware. > > > > v2: > > - move change to drm_lastclose() (Sima) > > - update docs for vga_switcheroo_process_delayed_switch() > > > > Signed-off-by: Thomas Zimmermann > > A bit an aside: The entire vgaswitcheroo code is still a midlayer mess, > where the locking is at the wrong layers resulting in the can_switch check > potentially being racy. But that's a different can of worms. Ok I got a bit annoyed about this mess again, and I think I have a reasonable idea for how to address it. Not sure why this took a decade, and definitely only pick this up if you're really bored. - We add a new vga_switcheroo_client_tryget, which checks the current state, and if it's on, increments a newly added refcount (which vgw switheroo maintains). Otherwise it fails. Drivers call this from their drm_driver->open hook. This check also allows us to drop the layer-violating checks in drm_open_helper for drm_dev->dev_power_state. - That refcount is dropped with vga_switcheroo_client_put, called from drm_driver->close. If the refcount drops to 0 this function also does delayed switch processing. - All the can_switch callbacks get removed and instead the vgwswr code directly consults its own refount. With this we don't have locking inversions anymore, and the old vgw switcheroo code works a lot more like the new mode based on runtime pm and power domains. With a bit more shuffling I think we can also ditch drm_driver->dev_power_state: - There's one in the intel backlight code, which is annoying, since it's wants to know whether the current callchain is from a vga switcheroo state change. But doable with a little helper. - Most others just want a vga_switcheroo_client_is_off() helper, which should be easy. Some are even entirely redundant, at least from a cursor callchain check. There's no races for these because they only matter during system suspend, since you should not mix both runtime and classic vgaswitcheroo logic. We might want some checks for that in that new helper ... - The one in the fbdev code is annoying, because it's another race. Ideally instead of that check it needs a call to vga_switcheroo_client_tryget/put just around the call to restore modes (we do not want fbdev to block state switches), but that probably means wiring a new callback through drm_client to drivers. - Might have missed a special case ... Anyway, I got nerdsniped, had an idea, figured best to type it up. Maybe we want to add a link to this to todo.rst, I think we have a vgaswitcheroo entry already. Cheers, Sima > > Reviewed-by: Daniel Vetter > > > --- > > drivers/gpu/drm/drm_file.c | 4 > > drivers/gpu/vga/vga_switcheroo.c | 3 +-- > > 2 files changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > > index 714e42b05108..513bef816ae9 100644 > > --- a/drivers/gpu/drm/drm_file.c > > +++ b/drivers/gpu/drm/drm_file.c > > @@ -38,6 +38,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -404,6 +405,9 @@ void drm_lastclose(struct drm_device * dev) > > drm_dbg_core(dev, "driver lastclose completed\n"); > > > > drm_client_dev_restore(dev); > > + > > + if (dev_is_pci(dev->dev)) > > + vga_switcheroo_process_delayed_switch(); > > } > > > > /** > > diff --git a/drivers/gpu/vga/vga_switcheroo.c > > b/drivers/gpu/vga/vga_switcheroo.c > > index 365e6ddbe90f..18f2c92beff8 100644 > > --- a/drivers/gpu/vga/vga_switcheroo.c > > +++ b/drivers/gpu/vga/vga_switcheroo.c > > @@ -926,8 +926,7 @@ static void vga_switcheroo_debugfs_init(struct > > vgasr_priv *priv) > > /** > > * vga_switcheroo_process_delayed_switch() - helper for delayed switching > > * > > - * Process a delayed switch if one is pending. DRM drivers should call this > > - * from their ->lastclose callback. > > + * Process a delayed switch if one is pending. > > * > > * Return: 0 on success. -EINVAL if no delayed switch is pending, if the > > client > > * has unregistered in the meantime or if there are other clients blocking > > the > > -- > > 2.46.0 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 7/9] drm/fbdev-helper: Remove drm_fb_helper_output_poll_changed()
On Mon, Aug 12, 2024 at 10:28:28AM +0200, Thomas Zimmermann wrote:
> The function is unused. Remove it.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 15 ---
> include/drm/drm_fb_helper.h | 6 --
> 2 files changed, 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index fe5667477839..29c53f9f449c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2003,18 +2003,3 @@ void drm_fb_helper_lastclose(struct drm_device *dev)
> drm_fb_helper_restore_fbdev_mode_unlocked(dev->fb_helper);
> }
> EXPORT_SYMBOL(drm_fb_helper_lastclose);
> -
> -/**
> - * drm_fb_helper_output_poll_changed - DRM mode config \.output_poll_changed
> - * helper for fbdev emulation
> - * @dev: DRM device
> - *
> - * This function can be used as the
> - * &drm_mode_config_funcs.output_poll_changed callback for drivers that only
> - * need to call drm_fbdev.hotplug_event().
> - */
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> - drm_fb_helper_hotplug_event(dev->fb_helper);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 375737fd6c36..699f2790b9ac 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -271,9 +271,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
> *fb_helper);
> int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper);
> int drm_fb_helper_debug_enter(struct fb_info *info);
> int drm_fb_helper_debug_leave(struct fb_info *info);
> -
> void drm_fb_helper_lastclose(struct drm_device *dev);
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev);
> #else
> static inline void drm_fb_helper_prepare(struct drm_device *dev,
>struct drm_fb_helper *helper,
> @@ -401,10 +399,6 @@ static inline int drm_fb_helper_debug_leave(struct
> fb_info *info)
> static inline void drm_fb_helper_lastclose(struct drm_device *dev)
> {
> }
> -
> -static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> -}
> #endif
>
> #endif
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 6/9] drm/fbdev-helper: Update documentation on obsolete callbacks
On Mon, Aug 12, 2024 at 10:28:27AM +0200, Thomas Zimmermann wrote:
> The old callbacks lastclose and output_poll_changed are deprecated and
> unused. Remove them from the documentation.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 3f7da78849e4..fe5667477839 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -89,14 +89,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
> * interfaces. Drivers that use one of the shared memory managers, TTM,
> SHMEM,
> * DMA, should instead use the corresponding fbdev emulation.
> *
> - * Existing fbdev implementations should restore the fbdev console by using
> - * drm_fb_helper_lastclose() as their &drm_driver.lastclose callback.
> - * They should also notify the fb helper code from updates to the output
> - * configuration by using drm_fb_helper_output_poll_changed() as their
> - * &drm_mode_config_funcs.output_poll_changed callback. New implementations
> - * of fbdev should be build on top of struct &drm_client_funcs, which handles
> - * this automatically. Setting the old callbacks should be avoided.
> - *
> * For suspend/resume consider using drm_mode_config_helper_suspend() and
> * drm_mode_config_helper_resume() which takes care of fbdev as well.
> *
> @@ -260,12 +252,12 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper,
> * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> * @fb_helper: driver-allocated fbdev helper, can be NULL
> *
> - * This should be called from driver's drm &drm_driver.lastclose callback
> - * when implementing an fbcon on top of kms using this helper. This ensures
> that
> - * the user isn't greeted with a black screen when e.g. X dies.
> + * This helper should be called from fbdev emulation's
> &drm_client_funcs.restore
> + * callback. It ensures that the user isn't greeted with a black screen when
> the
> + * userspace compositor releases the display device.
> *
> - * RETURNS:
> - * Zero if everything went ok, negative error code otherwise.
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> */
> int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
> *fb_helper)
> {
> @@ -2003,8 +1995,8 @@ EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
> * drm_fb_helper_lastclose - DRM driver lastclose helper for fbdev emulation
> * @dev: DRM device
> *
> - * This function can be used as the &drm_driver->lastclose callback for
> drivers
> - * that only need to call drm_fb_helper_restore_fbdev_mode_unlocked().
> + * This function is obsolete. Call
> drm_fb_helper_restore_fbdev_mode_unlocked()
> + * instead.
> */
> void drm_fb_helper_lastclose(struct drm_device *dev)
> {
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 3/9] drm/nouveau: Do not set struct drm_driver.lastclose
On Mon, Aug 12, 2024 at 10:28:24AM +0200, Thomas Zimmermann wrote:
> Remove the implementation of struct drm_driver.lastclose. The hook
> was only necessary before in-kernel DRM clients existed, but is now
> obsolete. The code in nouveau_vga_lastclose() is performed by
> drm_lastclose().
>
> v2:
> - update commit description
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_vga.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_vga.h | 1 -
> 3 files changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index ac7c60fb14d3..4a9a9b9c3935 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -1303,7 +1303,6 @@ driver_stub = {
> DRIVER_RENDER,
> .open = nouveau_drm_open,
> .postclose = nouveau_drm_postclose,
> - .lastclose = nouveau_vga_lastclose,
>
> #if defined(CONFIG_DEBUG_FS)
> .debugfs_init = nouveau_drm_debugfs_init,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index 2525e08938b3..ee637f1fe03d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -127,10 +127,3 @@ nouveau_vga_fini(struct nouveau_drm *drm)
> if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
> vga_switcheroo_fini_domain_pm_ops(drm->dev->dev);
> }
> -
> -
> -void
> -nouveau_vga_lastclose(struct drm_device *dev)
> -{
> - vga_switcheroo_process_delayed_switch();
> -}
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.h
> b/drivers/gpu/drm/nouveau/nouveau_vga.h
> index 951a83f984dd..63be415d2a44 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.h
> @@ -4,6 +4,5 @@
>
> void nouveau_vga_init(struct nouveau_drm *);
> void nouveau_vga_fini(struct nouveau_drm *);
> -void nouveau_vga_lastclose(struct drm_device *dev);
>
> #endif
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 2/9] drm/amdgpu: Do not set struct drm_driver.lastclose
On Mon, Aug 12, 2024 at 10:28:23AM +0200, Thomas Zimmermann wrote:
> Remove the implementation of struct drm_driver.lastclose. The hook
> was only necessary before in-kernel DRM clients existed, but is now
> obsolete. The code in amdgpu_driver_lastclose_kms() is performed by
> drm_lastclose().
>
> v2:
> - update commit message
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 17 -
> 3 files changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 137a88b8de45..4baeb6519fda 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1484,7 +1484,6 @@ extern const int amdgpu_max_kms_ioctl;
>
> int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags);
> void amdgpu_driver_unload_kms(struct drm_device *dev);
> -void amdgpu_driver_lastclose_kms(struct drm_device *dev);
> int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file
> *file_priv);
> void amdgpu_driver_postclose_kms(struct drm_device *dev,
>struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 094498a0964b..5dd39e6c6223 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2953,7 +2953,6 @@ static const struct drm_driver amdgpu_kms_driver = {
> DRIVER_SYNCOBJ_TIMELINE,
> .open = amdgpu_driver_open_kms,
> .postclose = amdgpu_driver_postclose_kms,
> - .lastclose = amdgpu_driver_lastclose_kms,
> .ioctls = amdgpu_ioctls_kms,
> .num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
> .dumb_create = amdgpu_mode_dumb_create,
> @@ -2980,7 +2979,6 @@ const struct drm_driver amdgpu_partition_driver = {
> DRIVER_SYNCOBJ_TIMELINE,
> .open = amdgpu_driver_open_kms,
> .postclose = amdgpu_driver_postclose_kms,
> - .lastclose = amdgpu_driver_lastclose_kms,
> .ioctls = amdgpu_ioctls_kms,
> .num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
> .dumb_create = amdgpu_mode_dumb_create,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 66782be5917b..0a799942343d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1269,23 +1269,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
> return 0;
> }
>
> -
> -/*
> - * Outdated mess for old drm with Xorg being in charge (void function now).
> - */
> -/**
> - * amdgpu_driver_lastclose_kms - drm callback for last close
> - *
> - * @dev: drm dev pointer
> - *
> - * Switch vga_switcheroo state after last close (all asics).
> - */
> -void amdgpu_driver_lastclose_kms(struct drm_device *dev)
> -{
> - drm_fb_helper_lastclose(dev);
> - vga_switcheroo_process_delayed_switch();
> -}
> -
> /**
> * amdgpu_driver_open_kms - drm callback for open
> *
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 1/9] drm: Do delayed switcheroo in drm_lastclose()
On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > their lastclose callbacks. Call it from drm_lastclose(), so that the > driver functions can finally be removed. Only PCI devices with enabled > switcheroo do the delayed switching. The call has no effect on other > hardware. > > v2: > - move change to drm_lastclose() (Sima) > - update docs for vga_switcheroo_process_delayed_switch() > > Signed-off-by: Thomas Zimmermann A bit an aside: The entire vgaswitcheroo code is still a midlayer mess, where the locking is at the wrong layers resulting in the can_switch check potentially being racy. But that's a different can of worms. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_file.c | 4 > drivers/gpu/vga/vga_switcheroo.c | 3 +-- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > index 714e42b05108..513bef816ae9 100644 > --- a/drivers/gpu/drm/drm_file.c > +++ b/drivers/gpu/drm/drm_file.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -404,6 +405,9 @@ void drm_lastclose(struct drm_device * dev) > drm_dbg_core(dev, "driver lastclose completed\n"); > > drm_client_dev_restore(dev); > + > + if (dev_is_pci(dev->dev)) > + vga_switcheroo_process_delayed_switch(); > } > > /** > diff --git a/drivers/gpu/vga/vga_switcheroo.c > b/drivers/gpu/vga/vga_switcheroo.c > index 365e6ddbe90f..18f2c92beff8 100644 > --- a/drivers/gpu/vga/vga_switcheroo.c > +++ b/drivers/gpu/vga/vga_switcheroo.c > @@ -926,8 +926,7 @@ static void vga_switcheroo_debugfs_init(struct vgasr_priv > *priv) > /** > * vga_switcheroo_process_delayed_switch() - helper for delayed switching > * > - * Process a delayed switch if one is pending. DRM drivers should call this > - * from their ->lastclose callback. > + * Process a delayed switch if one is pending. > * > * Return: 0 on success. -EINVAL if no delayed switch is pending, if the > client > * has unregistered in the meantime or if there are other clients blocking > the > -- > 2.46.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 8/8] drm: Remove struct drm_mode_config_funcs.output_poll_changed
On Wed, Aug 07, 2024 at 10:41:40AM +0200, Thomas Zimmermann wrote:
> The output_poll_changed hook in struct drm_mode_config_funcs is
> unused. Remove it. The helper drm_client_dev_hotplug() implements
> the callback's functionality.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_probe_helper.c | 10 +-
> include/drm/drm_mode_config.h | 16
> 2 files changed, 1 insertion(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 285290067056..92f21764246f 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -714,7 +714,7 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
> * @dev: drm_device whose connector state changed
> *
> * This function fires off the uevent for userspace and also calls the
> - * output_poll_changed function, which is most commonly used to inform the
> fbdev
> + * client hotplug function, which is most commonly used to inform the fbdev
> * emulation code and allow it to update the fbcon output configuration.
> *
> * Drivers should call this from their hotplug handling code when a change is
> @@ -730,11 +730,7 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
> */
> void drm_kms_helper_hotplug_event(struct drm_device *dev)
> {
> - /* send a uevent + call fbdev */
> drm_sysfs_hotplug_event(dev);
> - if (dev->mode_config.funcs->output_poll_changed)
> - dev->mode_config.funcs->output_poll_changed(dev);
> -
> drm_client_dev_hotplug(dev);
> }
> EXPORT_SYMBOL(drm_kms_helper_hotplug_event);
> @@ -750,11 +746,7 @@ void drm_kms_helper_connector_hotplug_event(struct
> drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
>
> - /* send a uevent + call fbdev */
> drm_sysfs_connector_hotplug_event(connector);
> - if (dev->mode_config.funcs->output_poll_changed)
> - dev->mode_config.funcs->output_poll_changed(dev);
> -
> drm_client_dev_hotplug(dev);
> }
> EXPORT_SYMBOL(drm_kms_helper_connector_hotplug_event);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab0f167474b1..271765e2e9f2 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -97,22 +97,6 @@ struct drm_mode_config_funcs {
>*/
> const struct drm_format_info *(*get_format_info)(const struct
> drm_mode_fb_cmd2 *mode_cmd);
>
> - /**
> - * @output_poll_changed:
> - *
> - * Callback used by helpers to inform the driver of output configuration
> - * changes.
> - *
> - * Drivers implementing fbdev emulation use
> drm_kms_helper_hotplug_event()
> - * to call this hook to inform the fbdev helper of output changes.
> - *
> - * This hook is deprecated, drivers should instead implement fbdev
> - * support with struct drm_client, which takes care of any necessary
> - * hotplug event forwarding already without further involvement by
> - * the driver.
> - */
> - void (*output_poll_changed)(struct drm_device *dev);
> -
> /**
>* @mode_valid:
>*
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 6/8] drm/fbdev-helper: Remove drm_fb_helper_output_poll_changed()
On Wed, Aug 07, 2024 at 10:41:38AM +0200, Thomas Zimmermann wrote:
> The function is unused. Remove it.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Without the next patch to remove ->lastclose there's some confusion text
left in the DOC: section in drm_fb_helper.c, but no point to split that up
perfectly imo. Was just trying to find it and didn't find it only looking
at the poll_changed patches ...
-Sima
> ---
> drivers/gpu/drm/drm_fb_helper.c | 15 ---
> include/drm/drm_fb_helper.h | 6 --
> 2 files changed, 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f6667dfba8a2..3cafb28236f7 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2015,18 +2015,3 @@ void drm_fb_helper_lastclose(struct drm_device *dev)
>
> }
> EXPORT_SYMBOL(drm_fb_helper_lastclose);
> -
> -/**
> - * drm_fb_helper_output_poll_changed - DRM mode config \.output_poll_changed
> - * helper for fbdev emulation
> - * @dev: DRM device
> - *
> - * This function can be used as the
> - * &drm_mode_config_funcs.output_poll_changed callback for drivers that only
> - * need to call drm_fbdev.hotplug_event().
> - */
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> - drm_fb_helper_hotplug_event(dev->fb_helper);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 375737fd6c36..699f2790b9ac 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -271,9 +271,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
> *fb_helper);
> int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper);
> int drm_fb_helper_debug_enter(struct fb_info *info);
> int drm_fb_helper_debug_leave(struct fb_info *info);
> -
> void drm_fb_helper_lastclose(struct drm_device *dev);
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev);
> #else
> static inline void drm_fb_helper_prepare(struct drm_device *dev,
>struct drm_fb_helper *helper,
> @@ -401,10 +399,6 @@ static inline int drm_fb_helper_debug_leave(struct
> fb_info *info)
> static inline void drm_fb_helper_lastclose(struct drm_device *dev)
> {
> }
> -
> -static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> -}
> #endif
>
> #endif
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 5/8] drm/nouveau: Implement switcheroo reprobe with drm_client_dev_hotplug()
On Wed, Aug 07, 2024 at 10:41:37AM +0200, Thomas Zimmermann wrote:
> Replace the callto drm_fb_helper_output_poll_changed() with a call
> to drm_client_dev_hotplug(). It's equivalent in functionality, but
> use the DRM client infrastructure.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index ee637f1fe03d..ab4e11dc0b8a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -58,8 +58,9 @@ static void
> nouveau_switcheroo_reprobe(struct pci_dev *pdev)
> {
> struct nouveau_drm *drm = pci_get_drvdata(pdev);
> + struct drm_device *dev = drm->dev;
>
> - drm_fb_helper_output_poll_changed(drm->dev);
> + drm_client_dev_hotplug(dev);
> }
>
> static bool
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 4/8] drm/nouveau: Do not set struct drm_mode_config_funcs.output_poll_changed
On Wed, Aug 07, 2024 at 10:41:36AM +0200, Thomas Zimmermann wrote:
> The output_poll_changed hook was only necessary before in-kernel
> DRM clients existed, but is now obsolete. The client code handles
> display otplugging internally.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index e4c8ce6dd40a..eed579a6c858 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2648,7 +2648,6 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev)
> static const struct drm_mode_config_funcs
> nv50_disp_func = {
> .fb_create = nouveau_user_framebuffer_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
> .atomic_check = nv50_disp_atomic_check,
> .atomic_commit = nv50_disp_atomic_commit,
> .atomic_state_alloc = nv50_disp_atomic_state_alloc,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 8a87e9697a42..e2fd561cd23f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -391,7 +391,6 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
>
> static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
> .fb_create = nouveau_user_framebuffer_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
> };
>
>
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/8] drm/fbdev-helper: Do delayed switcheroo in lastclose helper
On Wed, Aug 07, 2024 at 10:41:33AM +0200, Thomas Zimmermann wrote:
> Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from
> their lastclose callbacks. Call it from the fbdev lastclose helper,
> so that the driver functions can finally be removed.
>
> The fbdev call is part of all lastclose handling that restores the
> DRM fbcon terminal. Only PCI devices with enabled switcheroo do the
> delayed switching. The call has no effect on other drivers.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_fb_helper.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 3f7da78849e4..f6667dfba8a2 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2009,6 +2009,10 @@ EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
> void drm_fb_helper_lastclose(struct drm_device *dev)
> {
> drm_fb_helper_restore_fbdev_mode_unlocked(dev->fb_helper);
> +
> + if (dev_is_pci(dev->dev))
> + vga_switcheroo_process_delayed_switch();
I think if you want to move this, it needs to be in drm core. Otherwise
the vgaswitcheroo delayed switching stops working if you disable fbdev
support. Which doesn't make much sense.
-Sima
> +
> }
> EXPORT_SYMBOL(drm_fb_helper_lastclose);
>
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC] GPU driver with separate "core" and "DRM" modules
On Tue, Jun 18, 2024 at 04:23:17AM +1000, Ben Skeggs wrote: > On 17/6/24 23:55, Daniel Vetter wrote: > > > On Fri, Jun 14, 2024 at 03:02:09AM +1000, Ben Skeggs wrote: > > > NVIDIA has been exploring ways to better support the effort for an > > > upstream kernel mode driver for GPUs that are capable of running GSP-RM > > > firmware, since the introduction[1] to Nova. > > > > > > Use cases have been identified for which separating the core GPU > > > programming out of the full DRM driver stack is a strong requirement > > > from our key customers. > > > > > > An upstreamed NVIDIA GPU driver should be able to support current and > > > emerging customer use cases for vGPU hosts. NVIDIA's vGPU deployments > > > to date do not support compute or graphics functionality within the > > > hypervisor host, and have no dependency on the Linux graphics subsystem, > > > instead implementing the minimal functionality required to run vGPU > > > guest VMs. > > > > > > For security-sensitive environments such as cloud infrastructure, it's > > > important to continue support for running a minimal footprint vGPU host > > > driver in a stripped-down / barebones kernel environment. > > > > > > This can be achieved by supporting both VFIO and DRM drivers as clients > > > of a core driver, without requiring a full-fledged DRM driver (or the > > > DRM subsystem itself) to be built into the host kernel. > > > > > > A core driver would be responsible for booting and communicating with > > > GSP-RM, enumeration of HW configuration, shared/partitioned resource > > > management, exception handling, and event dispatch. > > > > > > The DRM driver would do all the standard things a DRM driver does, and > > > implement GPU memory management (TTM/HMM), KMS, command submission etc, > > > as well as providing UAPI for userspace clients. These features would > > > be implemented using HW resources allocated from a core driver, rather > > > than the DRM driver being directly responsible for HW programming. > > > > > > As Nouveau's KMD is already split (in the logical sense) along similar > > > lines, we're using it here for the purposes of this RFC to demonstrate > > > the feasibility of such an architecture, and open it up for discussion. > > Sounds reasonable. > > > > Only bikeshed I have to add is that the blessed way (according to the cool > > kernel maintainers at least or something) to structure this is using > > auxbus. Definitely when you end up with more than one driver binding to > > the core (like maybe some system management interface thing, or perhaps a > > special compute-only kernel driver). > > > > https://dri.freedesktop.org/docs/drm/driver-api/auxiliary_bus.html > > Hey! > > Yes indeed. I sent this[1] series at the same time, which was initially > written to so that nouveau.ko would still get auto-loaded alongside nvkm.ko. > > Ben. > > > [1] https://lists.freedesktop.org/archives/nouveau/2024-June/044861.html Oh I missed that you've already typed up the aux bus conversion somewhere. I guess just land it all :-) -Sima > > > > > > Cheers, Sima > > > > > A link[2] to a tree containing the patches is below. > > > > > > [1] > > > https://lore.kernel.org/all/3ed356488c9b0ca93845501425d427309f4cf616.ca...@redhat.com/ > > > [2] https://gitlab.freedesktop.org/bskeggs/nouveau/-/tree/00.03-module > > > > > > *** BLURB HERE *** > > > > > > Ben Skeggs (2): > > >drm/nouveau/nvkm: export symbols needed by the drm driver > > >drm/nouveau/nvkm: separate out into nvkm.ko > > > > > > drivers/gpu/drm/nouveau/Kbuild | 4 ++-- > > > drivers/gpu/drm/nouveau/include/nvkm/core/module.h | 3 --- > > > drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +- > > > drivers/gpu/drm/nouveau/nvkm/core/driver.c | 1 + > > > drivers/gpu/drm/nouveau/nvkm/core/gpuobj.c | 2 ++ > > > drivers/gpu/drm/nouveau/nvkm/core/mm.c | 4 > > > drivers/gpu/drm/nouveau/nvkm/device/acpi.c | 1 + > > > drivers/gpu/drm/nouveau/nvkm/engine/gr/base.c | 1 + > > > drivers/gpu/drm/nouveau/nvkm/module.c | 8 ++-- > > > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 1 + > > > drivers/gpu/drm/nouveau/nvkm/subdev/bios/pll.c | 1 + > > >
Re: [PATCH] nouveau: rip out busy fence waits
veau_fence *fence, bool lazy, bool intr)
> > +nouveau_fence_wait(struct nouveau_fence *fence, bool intr)
> > {
> > long ret;
> > - if (!lazy)
> > - return nouveau_fence_wait_busy(fence, intr);
> > -
> > ret = dma_fence_wait_timeout(&fence->base, intr, 15 * HZ);
> > if (ret < 0)
> > return ret;
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
> > b/drivers/gpu/drm/nouveau/nouveau_fence.h
> > index bc13110bdfa4..88213014b675 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_fence.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
> > @@ -23,7 +23,7 @@ void nouveau_fence_unref(struct nouveau_fence **);
> > int nouveau_fence_emit(struct nouveau_fence *);
> > bool nouveau_fence_done(struct nouveau_fence *);
> > -int nouveau_fence_wait(struct nouveau_fence *, bool lazy, bool intr);
> > +int nouveau_fence_wait(struct nouveau_fence *, bool intr);
> > int nouveau_fence_sync(struct nouveau_bo *, struct nouveau_channel *,
> > bool exclusive, bool intr);
> > struct nouveau_fence_chan {
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > index 49c2bcbef129..f715e381da69 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > @@ -928,7 +928,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
> > *data,
> > }
> > if (sync) {
> > - if (!(ret = nouveau_fence_wait(fence, false, false))) {
> > + if (!(ret = nouveau_fence_wait(fence, false))) {
> > if ((ret = dma_fence_get_status(&fence->base)) == 1)
> > ret = 0;
> > }
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC] GPU driver with separate "core" and "DRM" modules
On Fri, Jun 14, 2024 at 03:02:09AM +1000, Ben Skeggs wrote: > NVIDIA has been exploring ways to better support the effort for an > upstream kernel mode driver for GPUs that are capable of running GSP-RM > firmware, since the introduction[1] to Nova. > > Use cases have been identified for which separating the core GPU > programming out of the full DRM driver stack is a strong requirement > from our key customers. > > An upstreamed NVIDIA GPU driver should be able to support current and > emerging customer use cases for vGPU hosts. NVIDIA's vGPU deployments > to date do not support compute or graphics functionality within the > hypervisor host, and have no dependency on the Linux graphics subsystem, > instead implementing the minimal functionality required to run vGPU > guest VMs. > > For security-sensitive environments such as cloud infrastructure, it's > important to continue support for running a minimal footprint vGPU host > driver in a stripped-down / barebones kernel environment. > > This can be achieved by supporting both VFIO and DRM drivers as clients > of a core driver, without requiring a full-fledged DRM driver (or the > DRM subsystem itself) to be built into the host kernel. > > A core driver would be responsible for booting and communicating with > GSP-RM, enumeration of HW configuration, shared/partitioned resource > management, exception handling, and event dispatch. > > The DRM driver would do all the standard things a DRM driver does, and > implement GPU memory management (TTM/HMM), KMS, command submission etc, > as well as providing UAPI for userspace clients. These features would > be implemented using HW resources allocated from a core driver, rather > than the DRM driver being directly responsible for HW programming. > > As Nouveau's KMD is already split (in the logical sense) along similar > lines, we're using it here for the purposes of this RFC to demonstrate > the feasibility of such an architecture, and open it up for discussion. Sounds reasonable. Only bikeshed I have to add is that the blessed way (according to the cool kernel maintainers at least or something) to structure this is using auxbus. Definitely when you end up with more than one driver binding to the core (like maybe some system management interface thing, or perhaps a special compute-only kernel driver). https://dri.freedesktop.org/docs/drm/driver-api/auxiliary_bus.html Cheers, Sima > > A link[2] to a tree containing the patches is below. > > [1] > https://lore.kernel.org/all/3ed356488c9b0ca93845501425d427309f4cf616.ca...@redhat.com/ > [2] https://gitlab.freedesktop.org/bskeggs/nouveau/-/tree/00.03-module > > *** BLURB HERE *** > > Ben Skeggs (2): > drm/nouveau/nvkm: export symbols needed by the drm driver > drm/nouveau/nvkm: separate out into nvkm.ko > > drivers/gpu/drm/nouveau/Kbuild | 4 ++-- > drivers/gpu/drm/nouveau/include/nvkm/core/module.h | 3 --- > drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +- > drivers/gpu/drm/nouveau/nvkm/core/driver.c | 1 + > drivers/gpu/drm/nouveau/nvkm/core/gpuobj.c | 2 ++ > drivers/gpu/drm/nouveau/nvkm/core/mm.c | 4 > drivers/gpu/drm/nouveau/nvkm/device/acpi.c | 1 + > drivers/gpu/drm/nouveau/nvkm/engine/gr/base.c | 1 + > drivers/gpu/drm/nouveau/nvkm/module.c | 8 ++-- > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/bios/pll.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.c | 3 +++ > drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c | 3 +++ > drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 2 ++ > drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c| 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/volt/base.c | 1 + > 19 files changed, 33 insertions(+), 16 deletions(-) > > -- > 2.44.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] nouveau: offload fence uevents work to workqueue
On Tue, Feb 13, 2024 at 06:39:20PM +0100, Danilo Krummrich wrote: > On 2/9/24 19:52, Daniel Vetter wrote: > > On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote: > > > On 2/6/24 15:03, Daniel Vetter wrote: > > > > On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote: > > > > > On 2/5/24 22:08, Dave Airlie wrote: > > > > > > On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich > > > > > > wrote: > > > > > > > > > > > > > > On 1/29/24 02:50, Dave Airlie wrote: > > > > > > > > From: Dave Airlie > > > > > > > > > > > > > > > > This should break the deadlock between the fctx lock and the > > > > > > > > irq lock. > > > > > > > > > > > > > > > > This offloads the processing off the work from the irq into a > > > > > > > > workqueue. > > > > > > > > > > > > > > > > Signed-off-by: Dave Airlie > > > > > > > > > > > > > > Nouveau's scheduler uses a dedicated wq, hence from this > > > > > > > perspective it's > > > > > > > safe deferring fence signalling to the kernel global wq. However, > > > > > > > I wonder > > > > > > > if we could create deadlocks by building dependency chains into > > > > > > > other > > > > > > > drivers / kernel code that, by chance, makes use of the kernel > > > > > > > global wq as > > > > > > > well. > > > > > > > > > > > > > > Admittedly, even if, it's gonna be extremely unlikely given that > > > > > > > WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated > > > > > > > wq. > > > > > > > > > > > > > > Also, do we need to CC stable? > > > > > > > > > > > > I pushed this to Linus at the end of last week, since the hangs in > > > > > > 6.7 > > > > > > take out the complete system and I wanted it in stable. > > > > > > > > > > > > It might be safer to use a dedicated wq, is the concern someone is > > > > > > waiting on a fence in a workqueue somewhere else so we will never > > > > > > signal it? > > > > > > > > > > Yes, if some other work is waiting for this fence (or something else > > > > > in the same > > > > > dependency chain) to signal it can prevent executing the work > > > > > signaling this fence, > > > > > in case both are scheduled on the same wq. As mentioned, with the > > > > > kernel global wq > > > > > this would be rather unlikely to lead to an actual stall with > > > > > WQ_MAX_ACTIVE == 512, > > > > > but formally the race condition exists. I guess a malicious attacker > > > > > could try to > > > > > intentionally push jobs directly or indirectly depending on this > > > > > fence to a driver > > > > > which queues them up on a scheduler using the kernel global wq. > > > > > > > > I think if you add dma_fence_signalling annotations (aside, there's some > > > > patch from iirc Thomas Hellstrom to improve them and cut down on some > > > > false positives, but I lost track) then I think you won't get any splats > > > > because the wq subsystem assumes that WC_MAX_ACTIVE is close enough to > > > > infinity to not matter. > > > > > > As mentioned, for the kernel global wq it's 512. (Intentionally) feeding > > > the kernel > > > with enough jobs to to provoke a deadlock doesn't seem impossible to me. > > > > > > I think it'd be safer to just establish not to use the kernel global wq > > > for executing > > > work in the fence signalling critical path. > > > > > > We could also run into similar problems with a dedicated wq, e.g. when > > > drivers share > > > a wq between drm_gpu_scheduler instances (see [1]), however, I'm not sure > > > we can catch > > > that with lockdep. > > > > I think if you want to fix it perfectly you'd need to set the max number > > of wq to the number of engines (or for dynamic/fw scheduled engines to the >
Re: [PATCH] nouveau: offload fence uevents work to workqueue
On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote: > On 2/6/24 15:03, Daniel Vetter wrote: > > On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote: > > > On 2/5/24 22:08, Dave Airlie wrote: > > > > On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote: > > > > > > > > > > On 1/29/24 02:50, Dave Airlie wrote: > > > > > > From: Dave Airlie > > > > > > > > > > > > This should break the deadlock between the fctx lock and the irq > > > > > > lock. > > > > > > > > > > > > This offloads the processing off the work from the irq into a > > > > > > workqueue. > > > > > > > > > > > > Signed-off-by: Dave Airlie > > > > > > > > > > Nouveau's scheduler uses a dedicated wq, hence from this perspective > > > > > it's > > > > > safe deferring fence signalling to the kernel global wq. However, I > > > > > wonder > > > > > if we could create deadlocks by building dependency chains into other > > > > > drivers / kernel code that, by chance, makes use of the kernel global > > > > > wq as > > > > > well. > > > > > > > > > > Admittedly, even if, it's gonna be extremely unlikely given that > > > > > WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated wq. > > > > > > > > > > Also, do we need to CC stable? > > > > > > > > I pushed this to Linus at the end of last week, since the hangs in 6.7 > > > > take out the complete system and I wanted it in stable. > > > > > > > > It might be safer to use a dedicated wq, is the concern someone is > > > > waiting on a fence in a workqueue somewhere else so we will never > > > > signal it? > > > > > > Yes, if some other work is waiting for this fence (or something else in > > > the same > > > dependency chain) to signal it can prevent executing the work signaling > > > this fence, > > > in case both are scheduled on the same wq. As mentioned, with the kernel > > > global wq > > > this would be rather unlikely to lead to an actual stall with > > > WQ_MAX_ACTIVE == 512, > > > but formally the race condition exists. I guess a malicious attacker > > > could try to > > > intentionally push jobs directly or indirectly depending on this fence to > > > a driver > > > which queues them up on a scheduler using the kernel global wq. > > > > I think if you add dma_fence_signalling annotations (aside, there's some > > patch from iirc Thomas Hellstrom to improve them and cut down on some > > false positives, but I lost track) then I think you won't get any splats > > because the wq subsystem assumes that WC_MAX_ACTIVE is close enough to > > infinity to not matter. > > As mentioned, for the kernel global wq it's 512. (Intentionally) feeding the > kernel > with enough jobs to to provoke a deadlock doesn't seem impossible to me. > > I think it'd be safer to just establish not to use the kernel global wq for > executing > work in the fence signalling critical path. > > We could also run into similar problems with a dedicated wq, e.g. when > drivers share > a wq between drm_gpu_scheduler instances (see [1]), however, I'm not sure we > can catch > that with lockdep. I think if you want to fix it perfectly you'd need to set the max number of wq to the number of engines (or for dynamic/fw scheduled engines to the number of context) you have. Or whatever limit to the number of parallel timelines there is. I guess this would need a new wq function to update? drm/sched code could be able to set that for drivers, so drivers cannot get this wrong. If we don't do something like that then I'm not sure there's really much benefit - instead of carefully timing 512 dma_fence on the global wq you just need to create a pile of context (at least on intel's guc that's absolutely no issue) and then careful time them. I still feel like we have bigger fish to fry ... But might be worth the effort to at least make the parallel timeline limit a lot more explicit? Cheers, Sima > > [1] > https://elixir.bootlin.com/linux/v6.8-rc3/source/drivers/gpu/drm/nouveau/nouveau_drm.c#L313 > > > > > I'm not sure we should care differently, but I guess it'd be good to > > annotate it all in case the wq subsystem's idea of how much such deadlocks > > are real changes. > > > > Also Teo is on a mission to get rid of all the global wq flushes, so there > > should also be no source of deadlocks from that kind of cross-driver > > dependency. Or at least shouldn't be in the future, I'm not sure it all > > landed. > > -Sima > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] nouveau: offload fence uevents work to workqueue
On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote: > On 2/5/24 22:08, Dave Airlie wrote: > > On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote: > > > > > > On 1/29/24 02:50, Dave Airlie wrote: > > > > From: Dave Airlie > > > > > > > > This should break the deadlock between the fctx lock and the irq lock. > > > > > > > > This offloads the processing off the work from the irq into a workqueue. > > > > > > > > Signed-off-by: Dave Airlie > > > > > > Nouveau's scheduler uses a dedicated wq, hence from this perspective it's > > > safe deferring fence signalling to the kernel global wq. However, I wonder > > > if we could create deadlocks by building dependency chains into other > > > drivers / kernel code that, by chance, makes use of the kernel global wq > > > as > > > well. > > > > > > Admittedly, even if, it's gonna be extremely unlikely given that > > > WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated wq. > > > > > > Also, do we need to CC stable? > > > > I pushed this to Linus at the end of last week, since the hangs in 6.7 > > take out the complete system and I wanted it in stable. > > > > It might be safer to use a dedicated wq, is the concern someone is > > waiting on a fence in a workqueue somewhere else so we will never > > signal it? > > Yes, if some other work is waiting for this fence (or something else in the > same > dependency chain) to signal it can prevent executing the work signaling this > fence, > in case both are scheduled on the same wq. As mentioned, with the kernel > global wq > this would be rather unlikely to lead to an actual stall with WQ_MAX_ACTIVE > == 512, > but formally the race condition exists. I guess a malicious attacker could > try to > intentionally push jobs directly or indirectly depending on this fence to a > driver > which queues them up on a scheduler using the kernel global wq. I think if you add dma_fence_signalling annotations (aside, there's some patch from iirc Thomas Hellstrom to improve them and cut down on some false positives, but I lost track) then I think you won't get any splats because the wq subsystem assumes that WC_MAX_ACTIVE is close enough to infinity to not matter. I'm not sure we should care differently, but I guess it'd be good to annotate it all in case the wq subsystem's idea of how much such deadlocks are real changes. Also Teo is on a mission to get rid of all the global wq flushes, so there should also be no source of deadlocks from that kind of cross-driver dependency. Or at least shouldn't be in the future, I'm not sure it all landed. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] nouveau: rip out fence irq allow/block sequences.
> nouveau_fence_chan,
> -allow_block_work);
> -
> - if (atomic_read(&fctx->notify_ref) == 0)
> - nvif_event_block(&fctx->event);
> - else
> - nvif_event_allow(&fctx->event);
> -}
> -
> void
> nouveau_fence_context_new(struct nouveau_channel *chan, struct
> nouveau_fence_chan *fctx)
> {
> @@ -191,7 +164,6 @@ nouveau_fence_context_new(struct nouveau_channel *chan,
> struct nouveau_fence_cha
> } args;
> int ret;
>
> - INIT_WORK(&fctx->allow_block_work, nouveau_fence_work_allow_block);
> INIT_LIST_HEAD(&fctx->flip);
> INIT_LIST_HEAD(&fctx->pending);
> spin_lock_init(&fctx->lock);
> @@ -216,6 +188,12 @@ nouveau_fence_context_new(struct nouveau_channel *chan,
> struct nouveau_fence_cha
> &args.base, sizeof(args), &fctx->event);
>
> WARN_ON(ret);
> +
> + /*
> + * Always allow non-stall irq events - previously this code tried to
> + * enable/disable them, but that just seems racy as nonstall irqs are
> unlatched.
> + */
> + nvif_event_allow(&fctx->event);
> }
>
> int
> @@ -247,8 +225,7 @@ nouveau_fence_emit(struct nouveau_fence *fence)
> return -ENODEV;
> }
>
> - if (nouveau_fence_update(chan, fctx))
> - nvif_event_block(&fctx->event);
> + nouveau_fence_update(chan, fctx);
>
> list_add_tail(&fence->head, &fctx->pending);
> spin_unlock_irq(&fctx->lock);
> @@ -271,8 +248,8 @@ nouveau_fence_done(struct nouveau_fence *fence)
>
> spin_lock_irqsave(&fctx->lock, flags);
> chan = rcu_dereference_protected(fence->channel,
> lockdep_is_held(&fctx->lock));
> - if (chan && nouveau_fence_update(chan, fctx))
> - nvif_event_block(&fctx->event);
> + if (chan)
> + nouveau_fence_update(chan, fctx);
> spin_unlock_irqrestore(&fctx->lock, flags);
> }
> return dma_fence_is_signaled(&fence->base);
> @@ -530,32 +507,10 @@ static const struct dma_fence_ops
> nouveau_fence_ops_legacy = {
> .release = nouveau_fence_release
> };
>
> -static bool nouveau_fence_enable_signaling(struct dma_fence *f)
> -{
> - struct nouveau_fence *fence = from_fence(f);
> - struct nouveau_fence_chan *fctx = nouveau_fctx(fence);
> - bool ret;
> - bool do_work;
> -
> - if (atomic_inc_return(&fctx->notify_ref) == 0)
> - do_work = true;
> -
> - ret = nouveau_fence_no_signaling(f);
> - if (ret)
> - set_bit(DMA_FENCE_FLAG_USER_BITS, &fence->base.flags);
> - else if (atomic_dec_and_test(&fctx->notify_ref))
> - do_work = true;
> -
> - if (do_work)
> - schedule_work(&fctx->allow_block_work);
> -
> - return ret;
> -}
> -
> static const struct dma_fence_ops nouveau_fence_ops_uevent = {
> .get_driver_name = nouveau_fence_get_get_driver_name,
> .get_timeline_name = nouveau_fence_get_timeline_name,
> - .enable_signaling = nouveau_fence_enable_signaling,
> + .enable_signaling = nouveau_fence_no_signaling,
I think you can rip nouveau_fence_no_signaling out too, it doesn't do
anything more than what the signalling codepath does too.
But maybe separate path since maybe this makes an existing leak more of a
sieve, but it really should be an existing one since you cannot assume
that someone external will ever look at whether your fence is signalled or
not.
-Sima
> .signaled = nouveau_fence_is_signaled,
> .release = nouveau_fence_release
> };
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
> b/drivers/gpu/drm/nouveau/nouveau_fence.h
> index 28f5cf013b89..380bb0397ed2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
> @@ -46,8 +46,6 @@ struct nouveau_fence_chan {
> char name[32];
>
> struct nvif_event event;
> - struct work_struct allow_block_work;
> - atomic_t notify_ref;
> int dead, killed;
> };
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Nouveau] [PATCH drm-misc-next 2/3] drm/gpuva_mgr: generalize dma_resv/extobj handling and GEM validation
On Thu, Oct 12, 2023 at 02:35:15PM +0200, Christian König wrote: > Am 12.10.23 um 12:33 schrieb Dave Airlie: > > On Wed, 11 Oct 2023 at 17:07, Christian König > > wrote: > > > Am 10.10.23 um 22:23 schrieb Dave Airlie: > > > > > I think we're then optimizing for different scenarios. Our compute > > > > > driver will use mostly external objects only, and if shared, I don't > > > > > forsee them bound to many VMs. What saves us currently here is that in > > > > > compute mode we only really traverse the extobj list after a preempt > > > > > fence wait, or when a vm is using a new context for the first time. So > > > > > vm's extobj list is pretty large. Each bo's vma list will typically be > > > > > pretty small. > > > > Can I ask why we are optimising for this userspace, this seems > > > > incredibly broken. > > > > > > > > We've has this sort of problem in the past with Intel letting the tail > > > > wag the horse, does anyone remember optimising relocations for a > > > > userspace that didn't actually need to use relocations? > > > > > > > > We need to ask why this userspace is doing this, can we get some > > > > pointers to it? compute driver should have no reason to use mostly > > > > external objects, the OpenCL and level0 APIs should be good enough to > > > > figure this out. > > > Well that is pretty normal use case, AMD works the same way. > > > > > > In a multi GPU compute stack you have mostly all the data shared between > > > different hardware devices. > > > > > > As I said before looking at just the Vulcan use case is not a good idea > > > at all. > > > > > It's okay, I don't think anyone is doing that, some of the these > > use-cases are buried in server land and you guys don't communicate > > them very well. > > Yeah, well everybody is trying very hard to get away from those approaches > :) > > But so far there hasn't been any breakthrough. > > > > > multi-gpu compute would I'd hope be moving towards HMM/SVM type > > solutions though? > > Unfortunately not in the foreseeable future. HMM seems more and more like a > dead end, at least for AMD. > > AMD still has hardware support in all of their MI* products, but for Navi > the features necessary for implementing HMM have been dropped. And it looks > more and more like their are not going to come back. > > Additional to that from the software side Felix summarized it in the HMM > peer2peer discussion thread recently quite well. A buffer object based > approach is not only simpler to handle, but also performant vise multiple > magnitudes faster. This matches what I'm hearing from all over. Turns out that handling page faults in full generality in a compute/accel device (not just gpu) is just too damn hard. At least for anyone who isn't nvidia. Usually time bound preemption guarantees are the first to go, followed right after by a long list of more fixed function hardware blocks that outright can't cope with page faults. There's so many corner cases where it breaks down that I feel like device driver allocated memory of one flavor or another will stick around for a very long time. This isn't even counting the software challenges. -Sima > > I'm also not into looking at use-cases that used to be important but > > might not as important going forward. > > Well multimedia applications and OpenGL are still around, but it's not the > main focus any more. > > Christian. > > > > > Dave. > > > > > > > Christian. > > > > > > > Dave. > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [PATCH v10 00/19] drm: Analog TV Improvements
On Thu, Nov 17, 2022 at 10:28:43AM +0100, Maxime Ripard wrote: > Hi, > > Here's a series aiming at improving the command line named modes support, > and more importantly how we deal with all the analog TV variants. > > The named modes support were initially introduced to allow to specify the > analog TV mode to be used. > > However, this was causing multiple issues: > > * The mode name parsed on the command line was passed directly to the > driver, which had to figure out which mode it was suppose to match; > > * Figuring that out wasn't really easy, since the video= argument or what > the userspace might not even have a name in the first place, but > instead could have passed a mode with the same timings; > > * The fallback to matching on the timings was mostly working as long as > we were supporting one 525 lines (most likely NSTC) and one 625 lines > (PAL), but couldn't differentiate between two modes with the same > timings (NTSC vs PAL-M vs NSTC-J for example); > > * There was also some overlap with the tv mode property registered by > drm_mode_create_tv_properties(), but named modes weren't interacting > with that property at all. > > * Even though that property was generic, its possible values were > specific to each drivers, which made some generic support difficult. > > Thus, I chose to tackle in multiple steps: > > * A new TV mode property was introduced, with generic values, each driver > reporting through a bitmask what standard it supports to the userspace; > > * This option was added to the command line parsing code to be able to > specify it on the kernel command line, and new atomic_check and reset > helpers were created to integrate properly into atomic KMS; > > * The named mode parsing code is now creating a proper display mode for > the given named mode, and the TV standard will thus be part of the > connector state; > > * Two drivers were converted and tested for now (vc4 and sun4i), with > some backward compatibility code to translate the old TV mode to the > new TV mode; > > Unit tests were created along the way. > > One can switch from NTSC to PAL now using (on vc4) > > modetest -M vc4 -s 53:720x480i -w 53:'TV mode':1 # NTSC > modetest -M vc4 -s 53:720x576i -w 53:'TV mode':4 # PAL > > Let me know what you think, > Maxime Maxime asked me to drop an Ack-in-principle on this, and I'm not sure I have any useful input here with my utter lack of understanding for TV things (I never even had one in my entire life, that's how much I don't care). But it seems to check all the design boxes around solving annoying uapi/kms-config issues properly, so Acked-in-principle-or-something-like-that-by: Daniel Vetter Cheers, Daniel > > To: David Airlie > To: Daniel Vetter > To: Maarten Lankhorst > To: Maxime Ripard > To: Thomas Zimmermann > To: Emma Anholt > To: Jani Nikula > To: Joonas Lahtinen > To: Rodrigo Vivi > To: Tvrtko Ursulin > To: Ben Skeggs > To: Karol Herbst > To: Lyude Paul > To: Chen-Yu Tsai > To: Jernej Skrabec > To: Samuel Holland > Cc: Geert Uytterhoeven > Cc: Mateusz Kwiatkowski > Cc: "Noralf Trønnes" > Cc: Dave Stevenson > Cc: Dom Cobley > Cc: Phil Elwell > Cc: > Cc: linux-ker...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: nouveau@lists.freedesktop.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-su...@lists.linux.dev > Cc: Hans de Goede > Signed-off-by: Maxime Ripard > > --- > Changes in v10: > - Rebase on top of drm-misc-next-2022-11-17 > - Fix checkpatch issues > - Add missing MODULE_* macros > - Link to v9: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v9-0-24b168e5b...@cerno.tech > > Changes in v9: > - Rename some tests, switch to kunit_test_suite and parameterized tests where > relevant > - Document the valid named modes > - Link to v8: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v8-0-09ce14669...@cerno.tech > > Changes in v8: > - Changed slightly the helper API to pass in the features > - Removed unused tv_mode_support function > - Removed mode name match in _pick_cmdline_mode > - Added unit tests to the get_modes helper > - Collected Noralf and Mateusz tags > - Rebased on drm-misc-next-2022-11-10 > - Link to v7: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v7-0-7072a478c...@cerno.tech > > Changes in v7: > - Switch to another implementation of get_modes from Noralf > - Made more checks in VEC's atomic_check > - Fixed typo in a commit lo
Re: [Nouveau] [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
t device > > for the connector gets the right one and not merely the one > > which happened to get registered first. > > > > And I believe that having the panel brightness be a drm_connector > > property is the way to make it possible for userspace to deal > > with the multiple panels which each have a separate brightness > > control case. > > Agreed. > > Thanks for the explanations and recording them here. Can we stuff a summary of all the things we've discussed here into Documentation/gpu/todo.rst so that we have this recorded somewhere more permanently? Also good place to make sure everyone who was part of these discussions has a chance to ack the overall plan as part of merging such a patch. Just feels like this is big&complex enough to justify a todo entry with what's going on and what's still to be done. -Daniel > > BR, > Jani. > > > > > Regards, > > > > Hans > > > > > > > > > > > >> > >> BR, > >> Jani. > >> > >> > >>> > >>> This series implements my RFC describing my plan for these cleanups: > >>> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ > >>> > >>> Specifically patches 1-6 implement the "Fixing kms driver unconditionally > >>> register their "native" backlight dev" part. > >>> > >>> And patches 7-14 implement the "Fixing acpi_video0 getting registered for > >>> a brief time" time. > >>> > >>> Note this series does not deal yet with the "Other issues" part, I plan > >>> to do a follow up series for that. > >>> > >>> The changes in this series are good to have regardless of the further > >>> "drm/kms: control display brightness through drm_connector properties" > >>> plans. So I plan to push these upstream once they are ready (once > >>> reviewed). Since this crosses various subsystems / touches multiple > >>> kms drivers my plan is to provide an immutable branch based on say > >>> 5.19-rc1 and then have that get merged into all the relevant trees. > >>> > >>> Please review. > >>> > >>> Regards, > >>> > >>> Hans > >>> > >>> > >>> Hans de Goede (14): > >>> ACPI: video: Add a native function parameter to > >>> acpi_video_get_backlight_type() > >>> drm/i915: Don't register backlight when another backlight should be > >>> used > >>> drm/amdgpu: Don't register backlight when another backlight should be > >>> used > >>> drm/radeon: Don't register backlight when another backlight should be > >>> used > >>> drm/nouveau: Don't register backlight when another backlight should be > >>> used > >>> ACPI: video: Drop backlight_device_get_by_type() call from > >>> acpi_video_get_backlight_type() > >>> ACPI: video: Remove acpi_video_bus from list before tearing it down > >>> ACPI: video: Simplify acpi_video_unregister_backlight() > >>> ACPI: video: Make backlight class device registration a separate step > >>> ACPI: video: Remove code to unregister acpi_video backlight when a > >>> native backlight registers > >>> drm/i915: Call acpi_video_register_backlight() > >>> drm/nouveau: Register ACPI video backlight when nv_backlight > >>> registration fails > >>> drm/amdgpu: Register ACPI video backlight when skipping amdgpu > >>> backlight registration > >>> drm/radeon: Register ACPI video backlight when skipping radeon > >>> backlight registration > >>> > >>> drivers/acpi/acpi_video.c | 69 ++- > >>> drivers/acpi/video_detect.c | 53 +++--- > >>> drivers/gpu/drm/Kconfig | 2 + > >>> .../gpu/drm/amd/amdgpu/atombios_encoders.c| 14 +++- > >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++ > >>> .../gpu/drm/i915/display/intel_backlight.c| 7 ++ > >>> drivers/gpu/drm/i915/display/intel_display.c | 1 + > >>> drivers/gpu/drm/i915/display/intel_opregion.c | 2 +- > >>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 14 > >>> drivers/gpu/drm/radeon/atombios_encoders.c| 7 ++ > >>> drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++- > >>> .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 ++ > >>> drivers/platform/x86/acer-wmi.c | 2 +- > >>> drivers/platform/x86/asus-laptop.c| 2 +- > >>> drivers/platform/x86/asus-wmi.c | 4 +- > >>> drivers/platform/x86/compal-laptop.c | 2 +- > >>> drivers/platform/x86/dell/dell-laptop.c | 2 +- > >>> drivers/platform/x86/eeepc-laptop.c | 2 +- > >>> drivers/platform/x86/fujitsu-laptop.c | 4 +- > >>> drivers/platform/x86/ideapad-laptop.c | 2 +- > >>> drivers/platform/x86/intel/oaktrail.c | 2 +- > >>> drivers/platform/x86/msi-laptop.c | 2 +- > >>> drivers/platform/x86/msi-wmi.c| 2 +- > >>> drivers/platform/x86/samsung-laptop.c | 2 +- > >>> drivers/platform/x86/sony-laptop.c| 2 +- > >>> drivers/platform/x86/thinkpad_acpi.c | 4 +- > >>> drivers/platform/x86/toshiba_acpi.c | 2 +- > >>> include/acpi/video.h | 8 ++- > >>> 28 files changed, 156 insertions(+), 84 deletions(-) > >> > > > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [PATCH v3] dma-buf-map: Rename to iosys-map
On Thu, Feb 03, 2022 at 12:56:14AM -0800, Lucas De Marchi wrote: > Rename struct dma_buf_map to struct iosys_map and corresponding APIs. > Over time dma-buf-map grew up to more functionality than the one used by > dma-buf: in fact it's just a shim layer to abstract system memory, that > can be accessed via regular load and store, from IO memory that needs to > be acessed via arch helpers. > > The idea is to extend this API so it can fulfill other needs, internal > to a single driver. Example: in the i915 driver it's desired to share > the implementation for integrated graphics, which uses mostly system > memory, with discrete graphics, which may need to access IO memory. > > The conversion was mostly done with the following semantic patch: > > @r1@ > @@ > - struct dma_buf_map > + struct iosys_map > > @r2@ > @@ > ( > - DMA_BUF_MAP_INIT_VADDR > + IOSYS_MAP_INIT_VADDR > | > - dma_buf_map_set_vaddr > + iosys_map_set_vaddr > | > - dma_buf_map_set_vaddr_iomem > + iosys_map_set_vaddr_iomem > | > - dma_buf_map_is_equal > + iosys_map_is_equal > | > - dma_buf_map_is_null > + iosys_map_is_null > | > - dma_buf_map_is_set > + iosys_map_is_set > | > - dma_buf_map_clear > + iosys_map_clear > | > - dma_buf_map_memcpy_to > + iosys_map_memcpy_to > | > - dma_buf_map_incr > + iosys_map_incr > ) > > @@ > @@ > - #include > + #include > > Then some files had their includes adjusted and some comments were update to > remove mentions to dma-buf-map. > > Since this is not specific to dma-buf anymore, move the documentation to > the "Bus-Independent Device Accesses" section. > > v2: > - Squash patches > > v3: > - Fix wrong removal of dma-buf.h from MAINTAINERS > - Move documentation from dma-buf.rst to device-io.rst > > Signed-off-by: Lucas De Marchi > Acked-by: Christian König > Acked-by: Sumit Semwal Acked-by: Daniel Vetter > --- > Documentation/driver-api/device-io.rst| 9 + > Documentation/driver-api/dma-buf.rst | 9 - > Documentation/gpu/todo.rst| 20 +- > MAINTAINERS | 9 +- > drivers/dma-buf/dma-buf.c | 22 +- > drivers/dma-buf/heaps/cma_heap.c | 10 +- > drivers/dma-buf/heaps/system_heap.c | 10 +- > drivers/gpu/drm/ast/ast_drv.h | 2 +- > drivers/gpu/drm/ast/ast_mode.c| 8 +- > drivers/gpu/drm/drm_cache.c | 18 +- > drivers/gpu/drm/drm_client.c | 9 +- > drivers/gpu/drm/drm_fb_helper.c | 12 +- > drivers/gpu/drm/drm_gem.c | 12 +- > drivers/gpu/drm/drm_gem_cma_helper.c | 9 +- > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +- > drivers/gpu/drm/drm_gem_shmem_helper.c| 15 +- > drivers/gpu/drm/drm_gem_ttm_helper.c | 4 +- > drivers/gpu/drm/drm_gem_vram_helper.c | 25 +- > drivers/gpu/drm/drm_internal.h| 6 +- > drivers/gpu/drm/drm_mipi_dbi.c| 8 +- > drivers/gpu/drm/drm_prime.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +- > drivers/gpu/drm/gud/gud_pipe.c| 4 +- > drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 8 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 +- > .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 6 +- > drivers/gpu/drm/lima/lima_gem.c | 3 +- > drivers/gpu/drm/lima/lima_sched.c | 4 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.c| 7 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.h| 5 +- > drivers/gpu/drm/mgag200/mgag200_mode.c| 4 +- > drivers/gpu/drm/msm/msm_drv.h | 4 +- > drivers/gpu/drm/msm/msm_gem_prime.c | 6 +- > drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 13 +- > drivers/gpu/drm/qxl/qxl_display.c | 8 +- > drivers/gpu/drm/qxl/qxl_draw.c| 6 +- > drivers/gpu/drm/qxl/qxl_drv.h | 10 +- > drivers/gpu/drm/qxl/qxl_object.c | 8 +- > drivers/gpu/drm/qxl/qxl_object.h | 4 +- > drivers/gpu/drm/qxl/qxl_prime.c | 4 +- > drivers/gpu/drm/radeon/radeon_gem.c | 1 + > drivers/gpu/drm/rockchip/rockchip_drm_gem.c |
Re: [Nouveau] [PATCH 01/14] iosys-map: Introduce renamed dma-buf-map
gt; +/**
> > > > + * iosys_map_is_equal - Compares two iosys mapping structures
> > > > for equality
> > > > + * @lhs: The iosys_map structure
> > > > + * @rhs: A iosys_map structure to compare with
> > > > + *
> > > > + * Two iosys mapping structures are equal if they both refer to
> > > > the same type of memory
> > > > + * and to the same address within that memory.
> > > > + *
> > > > + * Returns:
> > > > + * True is both structures are equal, or false otherwise.
> > > > + */
> > > > +static inline bool iosys_map_is_equal(const struct iosys_map *lhs,
> > > > + const struct iosys_map *rhs)
> > > > +{
> > > > + if (lhs->is_iomem != rhs->is_iomem)
> > > > + return false;
> > > > + else if (lhs->is_iomem)
> > > > + return lhs->vaddr_iomem == rhs->vaddr_iomem;
> > > > + else
> > > > + return lhs->vaddr == rhs->vaddr;
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_is_null - Tests for a iosys mapping to be NULL
> > > > + * @map: The iosys_map structure
> > > > + *
> > > > + * Depending on the state of struct iosys_map.is_iomem, tests if the
> > > > + * mapping is NULL.
> > > > + *
> > > > + * Returns:
> > > > + * True if the mapping is NULL, or false otherwise.
> > > > + */
> > > > +static inline bool iosys_map_is_null(const struct iosys_map *map)
> > > > +{
> > > > + if (map->is_iomem)
> > > > + return !map->vaddr_iomem;
> > > > + return !map->vaddr;
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_is_set - Tests if the iosys mapping has been set
> > > > + * @map: The iosys_map structure
> > > > + *
> > > > + * Depending on the state of struct iosys_map.is_iomem, tests if the
> > > > + * mapping has been set.
> > > > + *
> > > > + * Returns:
> > > > + * True if the mapping is been set, or false otherwise.
> > > > + */
> > > > +static inline bool iosys_map_is_set(const struct iosys_map *map)
> > > > +{
> > > > + return !iosys_map_is_null(map);
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_clear - Clears a iosys mapping structure
> > > > + * @map: The iosys_map structure
> > > > + *
> > > > + * Clears all fields to zero, including struct iosys_map.is_iomem, so
> > > > + * mapping structures that were set to point to I/O memory are
> > > > reset for
> > > > + * system memory. Pointers are cleared to NULL. This is the default.
> > > > + */
> > > > +static inline void iosys_map_clear(struct iosys_map *map)
> > > > +{
> > > > + if (map->is_iomem) {
> > > > + map->vaddr_iomem = NULL;
> > > > + map->is_iomem = false;
> > > > + } else {
> > > > + map->vaddr = NULL;
> > > > + }
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_memcpy_to - Memcpy into iosys mapping
> > > > + * @dst: The iosys_map structure
> > > > + * @src: The source buffer
> > > > + * @len: The number of byte in src
> > > > + *
> > > > + * Copies data into a iosys mapping. The source buffer is in system
> > > > + * memory. Depending on the buffer's location, the helper picks
> > > > the correct
> > > > + * method of accessing the memory.
> > > > + */
> > > > +static inline void iosys_map_memcpy_to(struct iosys_map *dst,
> > > > const void *src,
> > > > + size_t len)
> > > > +{
> > > > + if (dst->is_iomem)
> > > > + memcpy_toio(dst->vaddr_iomem, src, len);
> > > > + else
> > > > + memcpy(dst->vaddr, src, len);
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_incr - Increments the address stored in a iosys mapping
> > > > + * @map: The iosys_map structure
> > > > + * @incr: The number of bytes to increment
> > > > + *
> > > > + * Increments the address stored in a iosys mapping. Depending on the
> > > > + * buffer's location, the correct value will be updated.
> > > > + */
> > > > +static inline void iosys_map_incr(struct iosys_map *map, size_t incr)
> > > > +{
> > > > + if (map->is_iomem)
> > > > + map->vaddr_iomem += incr;
> > > > + else
> > > > + map->vaddr += incr;
> > > > +}
> > > > +
> > > > +#endif /* __IOSYS_MAP_H__ */
> > >
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > > (HRB 36809, AG Nürnberg)
> > > Geschäftsführer: Ivo Totev
> >
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Nouveau] [RFC PATCH v6 0/3] Add support modifiers for drivers whose planes only support linear layout
On Fri, Jan 28, 2022 at 03:08:33PM +0900, Tomohito Esaki wrote: > Some drivers whose planes only support linear layout fb do not support format > modifiers. > These drivers should support modifiers, however the DRM core should handle > this > rather than open-coding in every driver. > > In this patch series, these drivers expose format modifiers based on the > following suggestion[1]. > > On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote: > > I think the best way forward here is: > > - add a new mode_config.cannot_support_modifiers flag, and enable > > this in radeon (plus any other drivers in the same boat) > > - change drm_universal_plane_init() to advertise the LINEAR modifier > > when NULL is passed as the modifier list (including installing a > > default .format_mod_supported hook) > > - remove the mode_config.allow_fb_modifiers hook and always > > advertise modifier support, unless > > mode_config.cannot_support_modifiers is set > > > [1] > https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-e...@igel.co.jp/#24602575 > > v6: > * add Reviewed-by and Acked-by > * add a changelog per-patch Thanks for resending with all that added, makes my life so much easier! All applied, thanks a bunch. Cheers, Daniel > > v5: https://www.spinics.net/lists/dri-devel/msg330860.html > * rebase to the latest master branch (5.17-rc1+) > + "drm/plane: Make format_mod_supported truly optional" patch [2] > [2] https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3 > > * change default_modifiers array from non-static to static > * remove terminator in default_modifiers array > * use ARRAY_SIZE to get the format_modifier_count > * keep a sanity check in plane init func > * modify several kerneldocs > > v4: https://www.spinics.net/lists/dri-devel/msg329508.html > * modify documentation for fb_modifiers_not_supported flag in kerneldoc > > v3: https://www.spinics.net/lists/dri-devel/msg329102.html > * change the order as follows: >1. add fb_modifiers_not_supported flag >2. add default modifiers >3. remove allow_fb_modifiers flag > * add a conditional disable in amdgpu_dm_plane_init() > > v2: https://www.spinics.net/lists/dri-devel/msg328939.html > * rebase to the latest master branch (5.16.0+) > + "drm/plane: Make format_mod_supported truly optional" patch [2] > > v1: https://www.spinics.net/lists/dri-devel/msg327352.html > * The initial patch set > > Tomohito Esaki (3): > drm: introduce fb_modifiers_not_supported flag in mode_config > drm: add support modifiers for drivers whose planes only support > linear layout > drm: remove allow_fb_modifiers > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 ++ > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 ++ > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 + > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++ > drivers/gpu/drm/drm_framebuffer.c | 6 ++--- > drivers/gpu/drm/drm_ioctl.c | 2 +- > drivers/gpu/drm/drm_plane.c | 23 +++ > drivers/gpu/drm/nouveau/nouveau_display.c | 6 +++-- > drivers/gpu/drm/radeon/radeon_display.c | 2 ++ > .../gpu/drm/selftests/test-drm_framebuffer.c | 1 - > include/drm/drm_mode_config.h | 18 +-- > include/drm/drm_plane.h | 3 +++ > 14 files changed, 45 insertions(+), 32 deletions(-) > > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [RFC PATCH v5 0/3] Add support modifiers for drivers whose planes only support linear layout
On Thu, Jan 27, 2022 at 12:25:36PM +0900, Tomohito Esaki wrote: > Some drivers whose planes only support linear layout fb do not support format > modifiers. > These drivers should support modifiers, however the DRM core should handle > this > rather than open-coding in every driver. > > In this patch series, these drivers expose format modifiers based on the > following suggestion[1]. > > On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote: > > I think the best way forward here is: > > - add a new mode_config.cannot_support_modifiers flag, and enable > > this in radeon (plus any other drivers in the same boat) > > - change drm_universal_plane_init() to advertise the LINEAR modifier > > when NULL is passed as the modifier list (including installing a > > default .format_mod_supported hook) > > - remove the mode_config.allow_fb_modifiers hook and always > > advertise modifier support, unless > > mode_config.cannot_support_modifiers is set > > > [1] > https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-e...@igel.co.jp/#24602575 Two procedural things: - There's an r-b on all the patches from Andy from the last round, please include that. - Please also include a changelog per-patch (at least going forward), that helps with judging where a patch series is. But aside from this I think this looks ready. Cheers, Daniel > > v5: > * rebase to the latest master branch (5.17-rc1+) > + "drm/plane: Make format_mod_supported truly optional" patch [2] > [2] https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3 > > * change default_modifiers array from non-static to static > * remove terminator in default_modifiers array > * use ARRAY_SIZE to get the format_modifier_count > * keep a sanity check in plane init func > * modify several kerneldocs > > v4: https://www.spinics.net/lists/dri-devel/msg329508.html > * modify documentation for fb_modifiers_not_supported flag in kerneldoc > > v3: https://www.spinics.net/lists/dri-devel/msg329102.html > * change the order as follows: >1. add fb_modifiers_not_supported flag >2. add default modifiers >3. remove allow_fb_modifiers flag > * add a conditional disable in amdgpu_dm_plane_init() > > v2: https://www.spinics.net/lists/dri-devel/msg328939.html > * rebase to the latest master branch (5.16.0+) > + "drm/plane: Make format_mod_supported truly optional" patch [2] > > v1: https://www.spinics.net/lists/dri-devel/msg327352.html > * The initial patch set > > Tomohito Esaki (3): > drm: introduce fb_modifiers_not_supported flag in mode_config > drm: add support modifiers for drivers whose planes only support > linear layout > drm: remove allow_fb_modifiers > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 ++ > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 ++ > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 + > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++ > drivers/gpu/drm/drm_framebuffer.c | 6 ++--- > drivers/gpu/drm/drm_ioctl.c | 2 +- > drivers/gpu/drm/drm_plane.c | 23 +++ > drivers/gpu/drm/nouveau/nouveau_display.c | 6 +++-- > drivers/gpu/drm/radeon/radeon_display.c | 2 ++ > .../gpu/drm/selftests/test-drm_framebuffer.c | 1 - > include/drm/drm_mode_config.h | 18 +-- > include/drm/drm_plane.h | 3 +++ > 14 files changed, 45 insertions(+), 32 deletions(-) > > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [PATCH 0/3] lib/string_helpers: Add a few string helpers
On Wed, Jan 19, 2022 at 04:16:12PM +0200, Jani Nikula wrote: > On Wed, 19 Jan 2022, Petr Mladek wrote: > > On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote: > >> Add some helpers under lib/string_helpers.h so they can be used > >> throughout the kernel. When I started doing this there were 2 other > >> previous attempts I know of, not counting the iterations each of them > >> had: > >> > >> 1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nik...@intel.com/ > >> 2) > >> https://lore.kernel.org/all/20210215142137.64476-1-andriy.shevche...@linux.intel.com/#t > >> > >> Going through the comments I tried to find some common ground and > >> justification for what is in here, addressing some of the concerns > >> raised. > >> > >> d. This doesn't bring onoff() helper as there are some places in the > >>kernel with onoff as variable - another name is probably needed for > >>this function in order not to shadow the variable, or those variables > >>could be renamed. Or if people wanting > >>try to find a short one > > > > I would call it str_on_off(). > > > > And I would actually suggest to use the same style also for > > the other helpers. > > > > The "str_" prefix would make it clear that it is something with > > string. There are other _on_off() that affect some > > functionality, e.g. mute_led_on_off(), e1000_vlan_filter_on_off(). > > > > The dash '_' would significantly help to parse the name. yesno() and > > onoff() are nicely short and kind of acceptable. But "enabledisable()" > > is a puzzle. > > > > IMHO, str_yes_no(), str_on_off(), str_enable_disable() are a good > > compromise. > > > > The main motivation should be code readability. You write the > > code once. But many people will read it many times. Open coding > > is sometimes better than misleading macro names. > > > > That said, I do not want to block this patchset. If others like > > it... ;-) > > I don't mind the names either way. Adding the prefix and dashes is > helpful in that it's possible to add the functions first and convert > users at leisure, though with a bunch of churn, while using names that > collide with existing ones requires the changes to happen in one go. > > What I do mind is grinding this series to a halt once again. I sent a > handful of versions of this three years ago, with inconclusive > bikeshedding back and forth, eventually threw my hands up in disgust, > and walked away. Yeah we can sed this anytime later we want to, but we need to get the foot in the door. There's also a pile more of these all over. Acked-by: Daniel Vetter on the series, maybe it helps? And yes let's merge this through drm-misc. -Daniel > > > > > > >> e. One alternative to all of this suggested by Christian König > >>(43456ba7-c372-84cc-4949-dcb817188...@amd.com) would be to add a > >>printk format. But besides the comment, he also seemed to like > >>the common function. This brought the argument from others that the > >>simple yesno()/enabledisable() already used in the code is easier to > >>remember and use than e.g. %py[DOY] > > > > Thanks for not going this way :-) > > > >> Last patch also has some additional conversion of open coded cases. I > >> preferred starting with drm/ since this is "closer to home". > >> > >> I hope this is a good summary of the previous attempts and a way we can > >> move forward. > >> > >> Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my > >> proposal is to take first 2 patches either through mm tree or maybe > >> vsprintf. Last patch can be taken later through drm. > > > > I agree with Andy that it should go via drm tree. It would make it > > easier to handle potential conflicts. > > > > Just in case, you decide to go with str_yes_no() or something similar. > > Mass changes are typically done at the end on the merge window. > > The best solution is when it can be done by a script. > > > > Best Regards, > > Petr > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [RFC PATH 1/3] drm: add support modifiers for drivers whose planes only support linear layout
ode_config.h b/include/drm/drm_mode_config.h
> index 48b7de80daf5..c56f298c55bd 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -920,6 +920,16 @@ struct drm_mode_config {
>*/
> bool allow_fb_modifiers;
>
> + /**
> + * @fb_modifiers_not_supported:
> + *
> + * This flag is for legacy drivers such as radeon that do not support
Maybe don't put specific driver names into kerneldoc (in commit message to
motivate your changes it's fine). It's unlikely radeon ever changes on
this, but also no one will update this in the docs if we ever do that.
Perhaps also add that new driver should never set this, just to hammer it
home that modifiers really should work everywhere.
Otherwise I think this series is the right thing to do.
-Daniel
> + * modifiers but infer the actual layout of the underlying buffer.
> + * Generally, each drivers must support modifiers, this flag should not
> + * be set.
> + */
> + bool fb_modifiers_not_supported;
> +
> /**
>* @normalize_zpos:
>*
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 0c1102dc4d88..cad641b1f797 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -803,6 +803,9 @@ void *__drmm_universal_plane_alloc(struct drm_device *dev,
> *
> * The @drm_plane_funcs.destroy hook must be NULL.
> *
> + * For drivers supporting modifiers, all planes will advertise
> + * DRM_FORMAT_MOD_LINEAR support, if @format_modifiers is not set.
> + *
> * Returns:
> * Pointer to new plane, or ERR_PTR on failure.
> */
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Nouveau] Regression in 5.15 in nouveau
On Tue, Dec 07, 2021 at 06:32:06PM +0100, Karol Herbst wrote: > On Tue, Dec 7, 2021 at 10:52 AM Christian König > wrote: > > > > Am 06.12.21 um 19:37 schrieb Dan Moulding: > > > On 04.12.21 17:40, Stefan Fritsch wrote: > > >> Hi, > > >> > > >> when updating from 5.14 to 5.15 on a system with NVIDIA GP108 [GeForce > > >> GT 1030] (NV138) and Ryzen 9 3900XT using kde/plasma on X (not wayland), > > >> there is a regression: There is now some annoying black flickering in > > >> some applications, for example thunderbird, firefox, or mpv. It mostly > > >> happens when scrolling or when playing video. Only the window of the > > >> application flickers, not the whole screen. But the flickering is not > > >> limited to the scrolled area: for example in firefox the url and > > >> bookmark bars flicker, too, not only the web site. I have bisected the > > >> issue to this commit: > > >> > > >> commit 3e1ad79bf66165bdb2baca3989f9227939241f11 (HEAD) > > > I have been experiencing this same issue since switching to 5.15. I > > > can confirm that reverting the above mentioned commit fixes the issue > > > for me. I'm on GP104 hardware (GeForce GTX 1070), also running KDE > > > Plasma on X. > > > > I'm still scratching my head what's going wrong here. > > > > Either we trigger some performance problem because we now wait twice for > > submissions or nouveau is doing something very nasty and not syncing > > it's memory accesses correctly. > > > > Attached is an only compile tested patch which might mitigate the first > > problem. > > > > But if it's the second then nouveau has a really nasty design issue here > > and somebody with more background on that driver design needs to take a > > look. > > > > Ben mentioned a few times that fences might be busted but we all have > no idea what's actually wrong. So it might be that your change is > indeed triggering something which was always broken or something else. Description sounds a bit like we're doing a clear before Xorg has had a chance to copy the pixmap to the frontbuffer perhaps? That would point to a fencing issue in userspace, and somehow ignoring fences ensures that the Xorg copy/blt completes before we get around to clearing stuff. I'm assuming we're rendering with glamour, so is nouveau relying on kernel implicit sync or doing it's own fencing in userspace? -Daniel > > > Please test if that patch changes anything. > > > > Thanks, > > Christian. > > > > > > > > Cheers, > > > > > > -- Dan > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [PATCH] MAINTAINERS: update information for nouveau
On Wed, Nov 10, 2021 at 02:31:57PM +0100, Karol Herbst wrote: > Some side notes on this. Atm we do want to use gitlab for bug tracking and > merge requests. But due to the nature of the current linux kernel > development, we can only do so for nouveau internal changes. > > Everything else still needs to be sent as emails and this is also includes > changes to UAPI etc. > > Anyway, if somebody wants to submit patches via gitlab, they are free to > do so and this should just make this more official and documented. > > People listed as maintainers are such that have push access to drm-misc > (where changes are pushed to after landing in gitlab) and are known > nouveau developers. > We did this already for some trivial changes and critical bug fixes > already, we just weren't thinking about updating the MAINTAINERS file. > > Cc: Ben Skeggs > Cc: Lyude Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-de...@lists.freedesktop.org > Cc: nouveau@lists.freedesktop.org > Signed-off-by: Karol Herbst Acked-by: Daniel Vetter > --- > MAINTAINERS | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8805df335326..270dc9c0a427 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5961,10 +5961,17 @@ F:drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS > M: Ben Skeggs > +M: Karol Herbst > +M: Lyude Paul > L: dri-de...@lists.freedesktop.org > L: nouveau@lists.freedesktop.org > S: Supported > -T: git git://github.com/skeggsb/linux > +W: https://nouveau.freedesktop.org/ > +Q: https://patchwork.freedesktop.org/project/nouveau/ > +Q: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests > +B: https://gitlab.freedesktop.org/drm/nouveau/-/issues > +C: irc://irc.oftc.net/nouveau > +T: git https://gitlab.freedesktop.org/drm/nouveau.git > F: drivers/gpu/drm/nouveau/ > F: include/uapi/drm/nouveau_drm.h > > -- > 2.33.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [PATCH] Revert "drm/fb-helper: improve DRM fbdev emulation device names"
On Fri, Oct 08, 2021 at 02:02:40PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 08, 2021 at 09:17:08AM +0200, Javier Martinez Canillas wrote:
> > This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
> >
> > That change attempted to improve the DRM drivers fbdev emulation device
> > names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
> >
> > But unfortunately there are user-space programs, such as pm-utils that
> > query that information and so broke after the mentioned commit. Since
> > the names in /proc/fb are used programs that consider it an ABI, let's
> > restore the old names even when this lead to silly naming like the one
> > mentioned above as an example.
>
> The usage Johannes listed was this specificially:
> using_kms() { grep -q -E '(nouveau|drm)fb' /proc/fb; }
>
>
> So it actually looks like Daniel's
> commit f243dd06180a ("drm/nouveau: Use drm_fb_helper_fill_info")
> also broke the abi. But for the pm-utils use case at least
> just having the "drmfb" in there should cover even nouveau.
>
> Cc: sta...@vger.kernel.org
> Reviewed-by: Ville Syrjälä
>
> >
> > Reported-by: Johannes Stezenbach
> > Signed-off-by: Javier Martinez Canillas
> > ---
> >
> > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 3ab07832104..8993b02e783 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1737,7 +1737,7 @@ void drm_fb_helper_fill_info(struct fb_info *info,
> >sizes->fb_width, sizes->fb_height);
> >
> > info->par = fb_helper;
> > - snprintf(info->fix.id, sizeof(info->fix.id), "%s",
Please add a comment here that drmfb is uapi because pm-utils matches
against it ...
Otherwise this will be lost in time again :-(
-Daniel
> > + snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
> > fb_helper->dev->driver->name);
> >
> > }
> > --
> > 2.31.1
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Nouveau] [PATCH 00/15] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Thu, Sep 16, 2021 at 11:15:37PM +0200, Fernando Ramos wrote:
> Hi all,
>
> One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
> patch series is about.
>
> You will find two types of changes here:
>
> - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate) with
> "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has
> already been done in previous commits such as b7ea04d2)
>
> - Replacing "drm_modeset_lock_all()" with
> "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> in the remaining places (as it has already been done in previous commits
> such as 57037094)
>
> Most of the changes are straight forward, except for a few cases in the "amd"
> and "i915" drivers where some extra dancing was needed to overcome the
> limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be used
> once inside the same function (the reason being that the macro expansion
> includes *labels*, and you can not have two labels named the same inside one
> function)
>
> Notice that, even after this patch series, some places remain where
> "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present,
> all inside drm core (which makes sense), except for two (in "amd" and "i915")
> which cannot be replaced due to the way they are being used.
Can we at least replace those with drm_modeset_lock_all_ctx and delete
drm_modeset_lock_all? That would be really nice goal to make sure these
don't spread further.
Otherwise great stuff, I'm trying to volunteer a few reviewers.
-Daniel
>
> Fernando Ramos (15):
> dmr: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
> dmr/i915: cleanup: drm_modeset_lock_all_ctx() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> dmr/msm: cleanup: drm_modeset_lock_all_ctx() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/shmobile: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/nouveau: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
>
> Documentation/gpu/todo.rst| 17 ---
> Documentation/locking/ww-mutex-design.rst | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +++--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 23 +
> drivers/gpu/drm/drm_client_modeset.c | 14 +++---
> drivers/gpu/drm/drm_crtc_helper.c | 18 ---
> drivers/gpu/drm/drm_fb_helper.c | 10 ++--
> drivers/gpu/drm/drm_framebuffer.c | 6 ++-
> drivers/gpu/drm/gma500/psb_device.c | 14 --
> drivers/gpu/drm/i915/display/intel_audio.c| 12 +++--
> drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
> .../drm/i915/display/intel_display_debugfs.c | 35 -
> drivers/gpu/drm/i915/display/intel_overlay.c | 45 -
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 5 +-
> drivers/gpu/drm/i915/i915_drv.c | 12 +++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++-
> .../gpu/drm/msm/disp/msm_disp_snapshot_util.c | 10 ++--
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 +++--
> drivers/gpu/drm/omapdrm/omap_fb.c | 6 ++-
> drivers/gpu/drm/radeon/radeon_device.c| 13 +++--
> drivers/gpu/drm/radeon/radeon_dp_mst.c| 7 ++-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++-
> drivers/gpu/drm/tegra/dsi.c | 6 ++-
> drivers/gpu/drm/tegra/hdmi.c | 5 +-
> drivers/gpu/drm/tegra/sor.c | 10 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +++--
> 28 files changed, 222 insertions(+), 180 deletions(-)
>
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Nouveau] Proposal for allowing more Nouveau contributors to merge patches
On Tue, Aug 10, 2021 at 01:38:27PM +0200, Karol Herbst wrote: > On Tue, Aug 10, 2021 at 12:11 PM Daniel Vetter wrote: > > > > On Fri, Aug 06, 2021 at 06:53:06PM +0200, Karol Herbst wrote: > > > Hey everybody, > > > > > > so, here is a proposal of what we could change in order to allow > > > patches to land faster, more reliably and to increase the overall bus > > > factor in terms of nouveau kernel maintenance. > > > > Yay! > > > > > But let's start with the current situation: > > > > > > At the moment contributors have to send patches to the nouveau mailing > > > list in order to submit them for inclusion into Bens nouveau tree. > > > Then Ben has to look at them and either respond with a comment on what > > > needs to change or merge it. At some point Ben submits all new changes > > > to nouveau for inclusion into the drm-next tree. > > > > > > Practically there are a few problems here: > > > 1. Not all patch submissions get a response > > > 2. Patch submitters usually don't get to know if their patches are > > > accepted unless they appear in drm-next or linus' tree. > > > 3. A lot of trivial patches never make it into the tree. > > > 4. Depending on how overloaded Ben is, even bigger patch series adding > > > new features never get any responses at all. > > > 5. Patch series might get stale for any other reason and there is no > > > good tool to track open patch submissions (no, patchwork isn't good > > > and it sucks and not even in the mood to explain this to people > > > thinking otherwise as this should just be obvious) > > > > > > This usually ends up discouraging new contributors from making more > > > contributions to nouveau as they see that some or all of their patches > > > never get any reaction and it's even annoying to current contributors > > > if they see their patches being stuck as well. > > > > > > And here I want to stress that none of this is Ben's fault and has his > > > own things to work on and none of this should just depend on one > > > person finding enough time. So the solution shouldn't be a simple > > > "let's find a different tool and everything should be perfect" but the > > > solution should be "how can we change the process so it's less time > > > consuming for Ben to accept patches". And while working on this, I'd > > > also want to tackle the problem that contributing to nouveau shouldn't > > > be frustrating for new contributors and the process should be more > > > lively overall. > > > > > > So for this I want to propose a new workflow, which would also spread > > > some responsibilities around active members of the nouveau community: > > > > > > 1. We should have a public nouveau tree (which could be > > > https://gitlab.freedesktop.org/drm/nouveau or something else) with a > > > nouveau-next branch collecting all patches for the next kernel major > > > kernel release. > > > At the moment the "official" nouveau tree is kind of > > > https://github.com/skeggsb/nouveau but there is > > > https://github.com/skeggsb/linux as well. The main problem is, it's a > > > repository tight to a person. We already have > > > https://gitlab.freedesktop.org/drm/nouveau as a bug tracker, but it > > > also contains a full linux git tree which is updated automatically > > > through a CI job. > > > > > > 2. A chosen group of people should have push rights to this repository > > > in order to accept patches sent in via emails to the nouveau Mailing > > > List or fancy UIs (like gitlabs MRs) or other ways. > > > Trusted contributors should be allowed to review and accept submitted > > > patches in order to reduce the workload on Ben. Those patches will be > > > collected on the nouveau-next branch. Patches from a mailing list > > > could e.g. be submitted through a MR on gitlab or just pushed to the > > > branch directly. > > > > > > 3. We should ensure through CI that submitted patches are at least > > > passing basic quality control (checkpatch, compile testing, sparse, > > > etc...) > > > I already worked on this and one example can be seen here: > > > https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/3 > > > There are more things we could add to it, like checking if sparse is > > > happy or add additional checks.
Re: [Nouveau] Proposal for allowing more Nouveau contributors to merge patches
it rights on drm/nouveau, Ben sends out the pull requests to drm-next for those, which gives him a good point to check over and do any last touches - directly push to drm-misc-next, defacto having a group commit right thing going on there directly Doing first commit rights and then resending the entire pile is way too much beaurocracy and wont solve much in my experience. This does mean that there's a lot of trust required for committers, since if the "drop/revert a patch" part becomes a regularity none of this works out. Otoh it also doesn't work out if committers aren't trusted, because then you're stuck in the "not really my problem" space. This is both from plenty of experience from other kernel teams trying to do something like this. If you don't have upfront trust, then commit rights/group maintainership model will simply not work, or at least be very painful. And yes this means occasionally things go wrong and need to be fixed up, and more importantly, a discussion about tooling, testing and review standards is likely required. For drm-misc/intel we handle those by asking for improvements to the dim tooling/docs anytime something goes wrong. This way hopefully the entire team learns. > 5. Urgent fixes should land via drm-fixes or drm-misc-fixes. > We kind of already do this already though. We could spin up a > nouveau-fixes branch in the future, but the amount of such fixes is so > low it's not really worth the effort at the moment. And we have access > to drm-misc. drm.git trees pretty much only take pull requests because Dave&me are lazy. We do push the occasionally hotfix if someone managed to set the tree on fire, but that's it (usually because we still suck at CI). Imo for fixes just make drm-misc the official place. > Once we decide to start and agree to some process, we should try it > out with trivial patches, we already get enough of. Like Typo fixes, > patches adding docs or removing dead code and can expand this to more > "serious" work once we agree that it actually works and does have > benefits to nouveau overall. > > Any thoughts on this? Imo start out with fixes in drm-misc-fixes, and leave feature work and anything substantial to the current skeggsb/nouveau process. Then reasses how that's going and what needs to be improved (like get the CI infra up and running meanwhile, maybe move the repo to drm/nouveau if you feel like, that kind of stuff). At least a get a bit a feeling for big stuff nouveau aint ready yet for group maintainership, judging from what you're proposing here. This also allows you to experiment around more with gitlab CI and maybe MR, perhaps nouveau will got directly to that for group maintainership (with Ben and Marge bot as sole committers)? Plus I think offloading and speeding up the simple fixes should help a lot already in making nouveau more alive and perhaps attracting new contributors. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 12:16:31PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
> >
> > On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > When the backlight support is disabled, the driver fails to build:
> > >
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > > 'nv50_sor_atomic_disable':
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > > nouveau_connector' has no member named 'backlight'
> > > 1665 | struct nouveau_backlight *backlight =
> > > nv_connector->backlight;
> > > | ^~
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > > undefined type 'struct nouveau_backlight'
> > > 1670 | if (backlight && backlight->uses_dpcd) {
> > > | ^~
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > > undefined type 'struct nouveau_backlight'
> > > 1671 | ret = drm_edp_backlight_disable(aux,
> > > &backlight->edp_info);
> > > |^~
> > >
> > > The patch that introduced the problem already contains some #ifdef
> > > checks, so just add another one that makes it build again.
> > >
> > > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > > support for nouveau")
> > > Signed-off-by: Arnd Bergmann
> >
> > Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
> > drm drivers using backlights, and add depends BACKLIGHT to all of
> > them?
> >
> > I mean this is a perfect source of continued patch streams to keep us
> > all busy, but beyond that I really don't see the point ... I frankly
> > have better things to do, and especially with the big drivers we have
> > making backlight optional saves comparitively nothing.
> > -Daniel
>
> Yes! I'd definitely be in favor of that, I've wasted way too much time trying
> to sort through dependency loops and other problems with backlight support.
>
> Maybe we should leave the drivers/video/fbdev/ drivers untouched in this
> regard, at least for the moment, but for the drivers/gpu/drm users of
> backlight that would be a nice simplification, and even the smallest ones
> are unlikely to be used on systems that are too memory constrained to
> deal with 4KB extra .text.
Yeah I think we can do this entirely ad-hoc, i.e. any time the backlight
wheel wobbles off again we nail it down for good for that driver with a
depends on BACKGLIGHT and remove any lingering #ifdef all over.
If you want maybe start out with the biggest drm drivers in a series, I
think if nouveau/amdgpu/i915 folks ack this you're good to go to just
convert as things get in the way.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When the backlight support is disabled, the driver fails to build:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> 'nv50_sor_atomic_disable':
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> nouveau_connector' has no member named 'backlight'
> 1665 | struct nouveau_backlight *backlight = nv_connector->backlight;
> | ^~
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> undefined type 'struct nouveau_backlight'
> 1670 | if (backlight && backlight->uses_dpcd) {
> | ^~
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> undefined type 'struct nouveau_backlight'
> 1671 | ret = drm_edp_backlight_disable(aux,
> &backlight->edp_info);
> |^~
>
> The patch that introduced the problem already contains some #ifdef
> checks, so just add another one that makes it build again.
>
> Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support
> for nouveau")
> Signed-off-by: Arnd Bergmann
Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
drm drivers using backlights, and add depends BACKLIGHT to all of
them?
I mean this is a perfect source of continued patch streams to keep us
all busy, but beyond that I really don't see the point ... I frankly
have better things to do, and especially with the big drivers we have
making backlight optional saves comparitively nothing.
-Daniel
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 093e1f7163b3..fcf53e24db21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1659,20 +1659,23 @@ static void
> nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state
> *state)
> {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> struct nouveau_connector *nv_connector =
> nv50_outp_get_old_connector(state, nv_encoder);
> - struct nouveau_backlight *backlight = nv_connector->backlight;
> struct drm_dp_aux *aux = &nv_connector->aux;
> - int ret;
> u8 pwr;
>
> +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> + struct nouveau_backlight *backlight = nv_connector->backlight;
> +
> if (backlight && backlight->uses_dpcd) {
> - ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
> + int ret = drm_edp_backlight_disable(aux,
> &backlight->edp_info);
> +
> if (ret < 0)
> NV_ERROR(drm, "Failed to disable backlight on
> [CONNECTOR:%d:%s]: %d\n",
> nv_connector->base.base.id,
> nv_connector->base.name, ret);
> }
> +#endif
>
> if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau broken again on Riva TNT2 in 5.14.0-rc2
On Thu, Jul 22, 2021 at 9:51 PM Karol Herbst wrote: > > hey thanks for the report. > > This is a known issue and the fix is pending in drm-mist-fixes and > should land in 5.14 soonish. It just landed in Linus' tree yesterday, please retest that or -rc3. If it's still broken it's something else. -Daniel > > On Thu, Jul 22, 2021 at 9:29 PM Ondrej Zary wrote: > > > > Hello, > > nouveau is broken again: > > > > [ 58.795794] BUG: kernel NULL pointer dereference, address: 017c > > [ 58.795835] #PF: supervisor read access in kernel mode > > [ 58.795844] #PF: error_code(0x) - not-present page > > [ 58.795851] *pde = > > [ 58.795862] Oops: [#1] SMP > > [ 58.795875] CPU: 0 PID: 1730 Comm: Xorg Not tainted 5.14.0-rc2+ #391 > > [ 58.795886] Hardware name: VIA Technologies, Inc. VT82C694X/694X, BIOS > > 6.00 PG 02/19/2002 > > [ 58.795894] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > > [ 58.796716] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 c0 01 00 00 fe 89 > > f0 e8 e5 ee ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 > > <03> 93 7c 01 00 00 0f b7 c1 f6 83 84 01 00 00 80 74 07 e8 8a bc 72 > > [ 58.796728] EAX: EBX: ECX: EDX: > > [ 58.796736] ESI: 0020 EDI: c18bc600 EBP: c7c49d88 ESP: c7c49d84 > > [ 58.796744] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210246 > > [ 58.796754] CR0: 80050033 CR2: 017c CR3: 07e12000 CR4: 0690 > > [ 58.796762] Call Trace: > > [ 58.796774] nv04_crtc_cursor_set+0x148/0x1d8 [nouveau] > > [ 58.796952] ? ttm_bo_reserve.constprop.16+0x1c/0x1c [nouveau] > > [ 58.797122] drm_mode_cursor_common+0x13b/0x1ad > > [ 58.797150] ? ttm_bo_reserve.constprop.16+0x1c/0x1c [nouveau] > > [ 58.797322] drm_mode_cursor_ioctl+0x2e/0x36 > > [ 58.797335] ? drm_mode_setplane+0x203/0x203 > > [ 58.797346] drm_ioctl_kernel+0x66/0x99 > > [ 58.797366] drm_ioctl+0x211/0x2d8 > > [ 58.797377] ? drm_mode_setplane+0x203/0x203 > > [ 58.797389] ? __cond_resched+0x1e/0x22 > > [ 58.797409] ? mutex_lock+0xb/0x24 > > [ 58.797422] ? rpm_resume.part.14+0x6f/0x362 > > [ 58.797447] ? ktime_get_mono_fast_ns+0x5e/0xf2 > > [ 58.797469] ? __pm_runtime_resume+0x5b/0x63 > > [ 58.797480] nouveau_drm_ioctl+0x65/0x81 [nouveau] > > [ 58.797662] ? nouveau_cli_work+0xc3/0xc3 [nouveau] > > [ 58.797838] vfs_ioctl+0x1a/0x24 > > [ 58.797850] __ia32_sys_ioctl+0x6ea/0x704 > > [ 58.797861] ? doublefault_shim+0x120/0x120 > > [ 58.797872] ? exit_to_user_mode_prepare+0x9e/0x10c > > [ 58.797900] do_int80_syscall_32+0x53/0x6e > > [ 58.797910] entry_INT80_32+0xf0/0xf0 > > [ 58.797923] EIP: 0xb7f04092 > > [ 58.797932] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 > > 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 > > 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 > > [ 58.797943] EAX: ffda EBX: 000e ECX: c01c64a3 EDX: bf9a15c0 > > [ 58.797952] ESI: 00997850 EDI: c01c64a3 EBP: 000e ESP: bf9a1574 > > [ 58.797959] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 00200292 > > [ 58.797972] Modules linked in: i2c_dev nouveau wmi hwmon drm_ttm_helper > > psmouse serio_raw via_agp sg parport_pc 8139cp parport > > [ 58.798016] CR2: 017c > > [ 58.798147] ---[ end trace 732829d39ed65de9 ]--- > > > > > > d02117f8efaa5fbc37437df1ae955a147a2a424a is the first bad commit > > > > -- > > Ondrej Zary > > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/7] vgaarb: remove VGA_DEFAULT_DEVICE
On Fri, Jul 16, 2021 at 09:14:02AM +0200, Christian König wrote: > Am 16.07.21 um 08:16 schrieb Christoph Hellwig: > > The define is entirely unused. > > > > Signed-off-by: Christoph Hellwig > > I'm not an expert for this particular code, but at least of hand everything > you do here makes totally sense. > > Whole series is Acked-by: Christian König Care to also push this into drm-misc-next since you looked already? -Daniel > > Regards, > Christian. > > > --- > > include/linux/vgaarb.h | 6 -- > > 1 file changed, 6 deletions(-) > > > > diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h > > index dc6ddce92066..26ec8a057d2a 100644 > > --- a/include/linux/vgaarb.h > > +++ b/include/linux/vgaarb.h > > @@ -42,12 +42,6 @@ > > #define VGA_RSRC_NORMAL_IO 0x04 > > #define VGA_RSRC_NORMAL_MEM0x08 > > -/* Passing that instead of a pci_dev to use the system "default" > > - * device, that is the one used by vgacon. Archs will probably > > - * have to provide their own vga_default_device(); > > - */ > > -#define VGA_DEFAULT_DEVICE (NULL) > > - > > struct pci_dev; > > /* For use by clients */ > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau: failed to initialise sync
On Wed, Jul 14, 2021 at 03:02:21PM +0200, Christian König wrote: > Am 14.07.21 um 14:56 schrieb Kirill A. Shutemov: > > On Tue, Jul 06, 2021 at 08:58:37AM +0200, Christian König wrote: > > > Hi guys, > > > > > > yes nouveau was using the same functionality for internal BOs without > > > noticing it. This is fixes by the following commit: > > > > > > commit d098775ed44021293b1962dea61efb19297b8d02 > > > Author: Christian König > > > Date: Wed Jun 9 19:25:56 2021 +0200 > > > > > > drm/nouveau: init the base GEM fields for internal BOs > > > > > > TTMs buffer objects are based on GEM objects for quite a while > > > and rely on initializing those fields before initializing the TTM BO. > > > > > > Nouveau now doesn't init the GEM object for internally allocated BOs, > > > so make sure that we at least initialize some necessary fields. > > > > > > Could be that the patch needs to be send to stable as well. > > The regression is present in v5.14-rc1. Any idea when it will hit > > upstream? I don't see it being applied to drm=next. > > Well that question needs to answer Dave or somebody else from the drm-misc > maintainer team. > > This fix together with some others are already in drm-misc-next-fixes > waiting to be pushed upstream, but it looks like that hasn't happened yet. > > Even Linus already pinged me where the fix for qxl got stuck. Yeah there was some missed patches. drm-misc-fixes is now in drm-fixes, and drm-misc-next-fixes is included in drm-misc-fixes, for which Thomas will do a pull request on Thu so it will land in -rc2. It should also now be in linux-next. But yes somehow bugfixes got a bit lost during the merge window. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 00/22] Deprecate struct drm_device.irq_enabled
On Tue, Jun 22, 2021 at 04:09:40PM +0200, Thomas Zimmermann wrote: > Remove references to struct drm_device.irq_enabled from modern > DRM drivers and core. > > KMS drivers enable IRQs for their devices internally. They don't > have to keep track of the IRQ state via irq_enabled. For vblanking, > it's cleaner to test for vblanking support directly than to test > for enabled IRQs. > > This used to be a single patch, [1] but it's now a full series. > > The first 3 patches replace instances of irq_enabled that are not > required. > > Patch 4 fixes vblank ioctls to actually test for vblank support > instead of IRQs. > > THe rest of the patchset removes irq_enabled from all non-legacy > drivers. The only exception is omapdrm, which has an internal > dpendency on the field's value. For this drivers, the state gets > duplicated internally. > > With the patchset applied, drivers can later switch over to plain > Linux IRQ interfaces and DRM's IRQ midlayer can be declared legacy. > > v2: > * keep the original test for legacy drivers in > drm_wait_vblank_ioctl() (Daniel) > > [1] > https://lore.kernel.org/dri-devel/20210608090301.4752-1-tzimmerm...@suse.de/ On the series: Acked-by: Daniel Vetter But I've only done a very light reading of this, so please wait for driver folks to have some time to check their own before merging. I think a devm_ version of drm_irq_install might be helpful in further untangling here, but that's definitely for another series. -Daniel > > Thomas Zimmermann (22): > drm/amdgpu: Track IRQ state in local device state > drm/hibmc: Call drm_irq_uninstall() unconditionally > drm/radeon: Track IRQ state in local device state > drm: Don't test for IRQ support in VBLANK ioctls > drm/komeda: Don't set struct drm_device.irq_enabled > drm/malidp: Don't set struct drm_device.irq_enabled > drm/exynos: Don't set struct drm_device.irq_enabled > drm/kirin: Don't set struct drm_device.irq_enabled > drm/imx: Don't set struct drm_device.irq_enabled > drm/mediatek: Don't set struct drm_device.irq_enabled > drm/nouveau: Don't set struct drm_device.irq_enabled > drm/omapdrm: Track IRQ state in local device state > drm/rockchip: Don't set struct drm_device.irq_enabled > drm/sti: Don't set struct drm_device.irq_enabled > drm/stm: Don't set struct drm_device.irq_enabled > drm/sun4i: Don't set struct drm_device.irq_enabled > drm/tegra: Don't set struct drm_device.irq_enabled > drm/tidss: Don't use struct drm_device.irq_enabled > drm/vc4: Don't set struct drm_device.irq_enabled > drm/vmwgfx: Don't set struct drm_device.irq_enabled > drm/xlnx: Don't set struct drm_device.irq_enabled > drm/zte: Don't set struct drm_device.irq_enabled > > drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 6 +++--- > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 > drivers/gpu/drm/arm/malidp_drv.c| 4 > drivers/gpu/drm/drm_irq.c | 10 +++--- > drivers/gpu/drm/drm_vblank.c| 13 + > drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 -- > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +-- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 -- > drivers/gpu/drm/imx/dcss/dcss-kms.c | 3 --- > drivers/gpu/drm/imx/imx-drm-core.c | 11 --- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 -- > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 --- > drivers/gpu/drm/omapdrm/omap_drv.h | 2 ++ > drivers/gpu/drm/omapdrm/omap_irq.c | 6 +++--- > drivers/gpu/drm/radeon/radeon_fence.c | 2 +- > drivers/gpu/drm/radeon/radeon_irq_kms.c | 16 > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 -- > drivers/gpu/drm/sti/sti_compositor.c| 2 -- > drivers/gpu/drm/stm/ltdc.c | 3 --- > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 -- > drivers/gpu/drm/tegra/drm.c | 7 --- > drivers/gpu/drm/tidss/tidss_irq.c | 3 --- > drivers/gpu/drm/vc4/vc4_kms.c | 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 8 > drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 -- > drivers/gpu/drm/zte/zx_drm_drv.c| 6 -- > 26 files changed, 30 insertions(+), 111 deletions(-) > > > base-commit: 8c1323b422f8473421682ba783b5949ddd89a3f4 > prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d > prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24 > -- > 2.32.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] drm/nouveau: wait for moving fence after pinning
On Mon, Jun 21, 2021 at 5:53 PM Daniel Vetter wrote:
>
> On Mon, Jun 21, 2021 at 5:49 PM Christian König
> wrote:
> >
> > Am 21.06.21 um 16:54 schrieb Daniel Vetter:
> > > On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> > >> We actually need to wait for the moving fence after pinning
> > >> the BO to make sure that the pin is completed.
> > >>
> > >> Signed-off-by: Christian König
> > >> CC: sta...@kernel.org
> > >> ---
> > >> drivers/gpu/drm/nouveau/nouveau_prime.c | 8 +++-
> > >> 1 file changed, 7 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
> > >> b/drivers/gpu/drm/nouveau/nouveau_prime.c
> > >> index 347488685f74..591738545eba 100644
> > >> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> > >> @@ -93,7 +93,13 @@ int nouveau_gem_prime_pin(struct drm_gem_object *obj)
> > >> if (ret)
> > >> return -EINVAL;
> > >>
> > >> -return 0;
> > >> +if (nvbo->bo.moving) {
> > > Don't we need to hold the dma_resv to read this? We can grab a reference
> > > and then unlock, but I think just unlocked wait can go boom pretty easily
> > > (since we don't hold a reference or lock so someone else can jump in and
> > > free the moving fence).
> >
> > The moving fence is only modified while the BO is moved and since we
> > have just successfully pinned it
>
> Yeah ... so probably correct, but really tricky. Just wrapping a
> ttm_bo_reserve/unreserve around the code you add should be enough and
> get the job done?
I think you distracted me a bit with the "it can't move", so yes
there's a guarantee that no other fence can show up in ttm_bo->moving
and confuse us. But it could get set to NULL because someone realized
it signalled. We're not doing that systematically, but relying on
fences never getting garbage-collected for correctness isn't great.
Sot the ttm_bo_reserve/unreserve is definitely needed here around this
bit of code. You don't need to merge it with the reserve/unreserve in
the pin function though, it's just to protect against the
use-after-free.
-Daniel
>
> > But in general I agree that it would be better to avoid this. I just
> > didn't wanted to open a bigger can of worms by changing nouveau so much.
>
> Yeah, but I'm kinda thinking of some helpers to wait for the move
> fence (so that later on we can switch from having the exclusive fence
> to the move fence do that, maybe). And then locking checks in there
> would be nice.
>
> Also avoids the case of explaining why lockless here is fine, but
> lockless wait for the exclusive fence in e.g. a dynami dma-buf
> importer is very much not fine at all. Just all around less trouble.
> -Daniel
>
> >
> > Christian.
> >
> > > -Daniel
> > >
> > >> +ret = dma_fence_wait(nvbo->bo.moving, true);
> > >> +if (ret)
> > >> +nouveau_bo_unpin(nvbo);
> > >> +}
> > >> +
> > >> +return ret;
> > >> }
> > >>
> > >> void nouveau_gem_prime_unpin(struct drm_gem_object *obj)
> > >> --
> > >> 2.25.1
> > >>
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] drm/nouveau: wait for moving fence after pinning
On Mon, Jun 21, 2021 at 5:49 PM Christian König
wrote:
>
> Am 21.06.21 um 16:54 schrieb Daniel Vetter:
> > On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> >> We actually need to wait for the moving fence after pinning
> >> the BO to make sure that the pin is completed.
> >>
> >> Signed-off-by: Christian König
> >> CC: sta...@kernel.org
> >> ---
> >> drivers/gpu/drm/nouveau/nouveau_prime.c | 8 +++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
> >> b/drivers/gpu/drm/nouveau/nouveau_prime.c
> >> index 347488685f74..591738545eba 100644
> >> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> >> @@ -93,7 +93,13 @@ int nouveau_gem_prime_pin(struct drm_gem_object *obj)
> >> if (ret)
> >> return -EINVAL;
> >>
> >> -return 0;
> >> +if (nvbo->bo.moving) {
> > Don't we need to hold the dma_resv to read this? We can grab a reference
> > and then unlock, but I think just unlocked wait can go boom pretty easily
> > (since we don't hold a reference or lock so someone else can jump in and
> > free the moving fence).
>
> The moving fence is only modified while the BO is moved and since we
> have just successfully pinned it
Yeah ... so probably correct, but really tricky. Just wrapping a
ttm_bo_reserve/unreserve around the code you add should be enough and
get the job done?
> But in general I agree that it would be better to avoid this. I just
> didn't wanted to open a bigger can of worms by changing nouveau so much.
Yeah, but I'm kinda thinking of some helpers to wait for the move
fence (so that later on we can switch from having the exclusive fence
to the move fence do that, maybe). And then locking checks in there
would be nice.
Also avoids the case of explaining why lockless here is fine, but
lockless wait for the exclusive fence in e.g. a dynami dma-buf
importer is very much not fine at all. Just all around less trouble.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> >> + ret = dma_fence_wait(nvbo->bo.moving, true);
> >> +if (ret)
> >> +nouveau_bo_unpin(nvbo);
> >> +}
> >> +
> >> +return ret;
> >> }
> >>
> >> void nouveau_gem_prime_unpin(struct drm_gem_object *obj)
> >> --
> >> 2.25.1
> >>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] drm/amdgpu: wait for moving fence after pinning
On Mon, Jun 21, 2021 at 03:03:28PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index baa980a477d9..37ec59365080 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -214,9 +214,21 @@ static int amdgpu_dma_buf_pin(struct dma_buf_attachment
> *attach)
> {
> struct drm_gem_object *obj = attach->dmabuf->priv;
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> + int r;
>
> /* pin buffer into GTT */
> - return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> + r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> + if (r)
> + return r;
> +
> + if (bo->tbo.moving) {
dma-buf.c guarantees we have the reservation here, so we're fine.
Reviewed-by: Daniel Vetter
> + r = dma_fence_wait(bo->tbo.moving, true);
> + if (r) {
> + amdgpu_bo_unpin(bo);
> + return r;
> + }
> + }
> + return 0;
> }
>
> /**
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/radeon: wait for moving fence after pinning
On Mon, Jun 21, 2021 at 03:03:27PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_prime.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index 42a87948e28c..4a90807351e7 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -77,9 +77,19 @@ int radeon_gem_prime_pin(struct drm_gem_object *obj)
>
> /* pin buffer into GTT */
> ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
> - if (likely(ret == 0))
> - bo->prime_shared_count++;
> -
> + if (unlikely(ret))
> + goto error;
> +
> + if (bo->tbo.moving) {
> + ret = dma_fence_wait(bo->tbo.moving, false);
Here we wait whil holding the reservation, so we should be all fine. Maybe
not the nicest to wait while locked, but also I don't think it'll matter.
Reviewed-by: Daniel Vetter
> + if (unlikely(ret)) {
> + radeon_bo_unpin(bo);
> + goto error;
> + }
> + }
> +
> + bo->prime_shared_count++;
> +error:
> radeon_bo_unreserve(bo);
> return ret;
> }
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] drm/nouveau: wait for moving fence after pinning
On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/nouveau/nouveau_prime.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
> b/drivers/gpu/drm/nouveau/nouveau_prime.c
> index 347488685f74..591738545eba 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> @@ -93,7 +93,13 @@ int nouveau_gem_prime_pin(struct drm_gem_object *obj)
> if (ret)
> return -EINVAL;
>
> - return 0;
> + if (nvbo->bo.moving) {
Don't we need to hold the dma_resv to read this? We can grab a reference
and then unlock, but I think just unlocked wait can go boom pretty easily
(since we don't hold a reference or lock so someone else can jump in and
free the moving fence).
-Daniel
> + ret = dma_fence_wait(nvbo->bo.moving, true);
> + if (ret)
> + nouveau_bo_unpin(nvbo);
> + }
> +
> + return ret;
> }
>
> void nouveau_gem_prime_unpin(struct drm_gem_object *obj)
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND 00/26] Rid W=1 warnings from GPU
On Wed, Jun 02, 2021 at 03:32:34PM +0100, Lee Jones wrote:
> Some off these patches have been knocking around for a while.
>
> Who will hoover them up please?
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> Lee Jones (26):
> drm/mediatek/mtk_disp_color: Strip incorrect doc and demote header
> drm/mediatek/mtk_disp_gamma: Strip and demote non-conformant
> kernel-doc header
> drm/mediatek/mtk_disp_ovl: Strip and demote non-conformant header
> drm/mediatek/mtk_disp_rdma: Strip and demote non-conformant kernel-doc
> header
> drm/sti/sti_hdmi_tx3g4c28phy: Provide function names for kernel-doc
> headers
> drm/sti/sti_hda: Provide missing function names
> drm/sti/sti_tvout: Provide a bunch of missing function names
> drm/sti/sti_hqvdp: Fix incorrectly named function 'sti_hqvdp_vtg_cb()'
> drm/msm/disp/dpu1/dpu_encoder_phys_cmd: Remove unused variable
> 'cmd_enc'
> drm/msm/disp/dpu1/dpu_hw_interrupts: Demote a bunch of kernel-doc
> abuses
> drm/msm/disp/dpu1/dpu_plane: Fix a couple of naming issues
> drm/msm/msm_gem: Demote kernel-doc abuses
> drm/msm/dp/dp_catalog: Correctly document param 'dp_catalog'
> drm/msm/dp/dp_link: Fix some potential doc-rot
> drm/nouveau/nvkm/subdev/mc/tu102: Make functions called by reference
> static
> drm/amd/display/dc/dce/dce_transform: Remove superfluous
> re-initialisation of DCFE_MEM_LIGHT_SLEEP_CNTL,
> drm/xlnx/zynqmp_disp: Fix incorrectly named enum
> 'zynqmp_disp_layer_id'
> drm/xlnx/zynqmp_dp: Fix incorrectly name function 'zynqmp_dp_train()'
> drm/ttm/ttm_tt: Demote non-conformant kernel-doc header
> drm/panel/panel-raspberrypi-touchscreen: Demote kernel-doc abuse
> drm/panel/panel-sitronix-st7701: Demote kernel-doc abuse
> drm/vgem/vgem_drv: Standard comment blocks should not use kernel-doc
> format
> drm/exynos/exynos7_drm_decon: Fix incorrect naming of
> 'decon_shadow_protect_win()'
> drm/exynos/exynos_drm_ipp: Fix documentation for
> 'exynos_drm_ipp_get_{caps,res}_ioctl()'
> drm/vboxvideo/hgsmi_base: Place function names into headers
> drm/vboxvideo/modesetting: Provide function names for prototype
> headers
Except for msm (Rob Clark promised on irc he'll pick them up for 5.14
soon) and amd (Alex is on top of things I think) I picked them all up and
merged into drm-misc-next.
Thanks, Daniel
>
> .../drm/amd/display/dc/dce/dce_transform.h| 3 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 +--
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 4 +--
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 +--
> .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ---
> .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 32 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 +--
> drivers/gpu/drm/msm/dp/dp_catalog.c | 2 +-
> drivers/gpu/drm/msm/dp/dp_link.c | 6 ++--
> drivers/gpu/drm/msm/msm_gem.c | 4 +--
> .../gpu/drm/nouveau/nvkm/subdev/mc/tu102.c| 6 ++--
> .../drm/panel/panel-raspberrypi-touchscreen.c | 2 +-
> drivers/gpu/drm/panel/panel-sitronix-st7701.c | 2 +-
> drivers/gpu/drm/sti/sti_hda.c | 6 ++--
> drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c| 4 +--
> drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
> drivers/gpu/drm/sti/sti_tvout.c | 18 +--
> drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
> drivers/gpu/drm/vboxvideo/hgsmi_base.c| 19 +++
> drivers/gpu/drm/vboxvideo/modesetting.c | 20 +++-
> drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_disp.c| 2 +-
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 26 files changed, 80 insertions(+), 82 deletions(-)
>
> Cc: Adam Jackson
> Cc: Ajay Kumar
> Cc: Akshu Agarwal
> Cc: Alex Deucher
> Cc: Alistair Popple
> Cc: amd-...@lists.freedesktop.org
> Cc: AngeloGioacchino Del Regno
> Cc: Benjamin Gaignard
> Cc: Ben Skeggs
> Cc: Ben Widawsky
> Cc: Chandan Uddaraju
> Cc: Christian Koenig
> Cc: "Christian König"
> Cc: Chun-Kuang Hu
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Fabien Dessenne
> Cc: freedr...@lists.freedesktop.org
> Cc: Hans de Goede
> Cc: Harry Wentland
Re: [Nouveau] [Intel-gfx] [PATCH 0/7] Per client engine busyness
On Wed, May 19, 2021 at 11:17:24PM +, Nieto, David M wrote: > [AMD Official Use Only] > > Parsing over 550 processes for fdinfo is taking between 40-100ms single > threaded in a 2GHz skylake IBRS within a VM using simple string > comparisons and DIRent parsing. And that is pretty much the worst case > scenario with some more optimized implementations. I think this is plenty ok, and if it's not you could probably make this massively faster with io_uring for all the fs operations and whack a parser-generator on top for real parsing speed. So imo we shouldn't worry about algorithmic inefficiency of the fdinfo approach at all, and focuse more on trying to reasonably (but not too much, this is still drm render stuff after all) standardize how it works and how we'll extend it all. I think there's tons of good suggestions in this thread on this topic already. /me out -Daniel > > David > ____ > From: Daniel Vetter > Sent: Wednesday, May 19, 2021 11:23 AM > To: Tvrtko Ursulin > Cc: Daniel Stone ; jhubb...@nvidia.com > ; nouveau@lists.freedesktop.org > ; Intel Graphics Development > ; Maling list - DRI developers > ; Simon Ser ; Koenig, > Christian ; arit...@nvidia.com > ; Nieto, David M > Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness > > On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin > wrote: > > > > > > On 18/05/2021 10:40, Tvrtko Ursulin wrote: > > > > > > On 18/05/2021 10:16, Daniel Stone wrote: > > >> Hi, > > >> > > >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin > > >> wrote: > > >>> I was just wondering if stat(2) and a chrdev major check would be a > > >>> solid criteria to more efficiently (compared to parsing the text > > >>> content) detect drm files while walking procfs. > > >> > > >> Maybe I'm missing something, but is the per-PID walk actually a > > >> measurable performance issue rather than just a bit unpleasant? > > > > > > Per pid and per each open fd. > > > > > > As said in the other thread what bothers me a bit in this scheme is that > > > the cost of obtaining GPU usage scales based on non-GPU criteria. > > > > > > For use case of a top-like tool which shows all processes this is a > > > smaller additional cost, but then for a gpu-top like tool it is somewhat > > > higher. > > > > To further expand, not only cost would scale per pid multiplies per open > > fd, but to detect which of the fds are DRM I see these three options: > > > > 1) Open and parse fdinfo. > > 2) Name based matching ie /dev/dri/.. something. > > 3) Stat the symlink target and check for DRM major. > > stat with symlink following should be plenty fast. > > > All sound quite sub-optimal to me. > > > > Name based matching is probably the least evil on system resource usage > > (Keeping the dentry cache too hot? Too many syscalls?), even though > > fundamentally I don't it is the right approach. > > > > What happens with dup(2) is another question. > > We need benchmark numbers showing that on anything remotely realistic > it's an actual problem. Until we've demonstrated it's a real problem > we don't need to solve it. > > E.g. top with any sorting enabled also parses way more than it > displays on every update. It seems to be doing Just Fine (tm). > > > Does anyone have any feedback on the /proc//gpu idea at all? > > When we know we have a problem to solve we can take a look at solutions. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&data=04%7C01%7CDavid.Nieto%40amd.com%7Cf6aea97532cf41f916de08d91af32cc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637570453997158377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4CFrY9qWbJREcIcSzeO9KIn2P%2Fw6k%2BYdNlh6rdS%2BEh4%3D&reserved=0 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH 0/7] Per client engine busyness
On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin wrote: > > > On 18/05/2021 10:40, Tvrtko Ursulin wrote: > > > > On 18/05/2021 10:16, Daniel Stone wrote: > >> Hi, > >> > >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin > >> wrote: > >>> I was just wondering if stat(2) and a chrdev major check would be a > >>> solid criteria to more efficiently (compared to parsing the text > >>> content) detect drm files while walking procfs. > >> > >> Maybe I'm missing something, but is the per-PID walk actually a > >> measurable performance issue rather than just a bit unpleasant? > > > > Per pid and per each open fd. > > > > As said in the other thread what bothers me a bit in this scheme is that > > the cost of obtaining GPU usage scales based on non-GPU criteria. > > > > For use case of a top-like tool which shows all processes this is a > > smaller additional cost, but then for a gpu-top like tool it is somewhat > > higher. > > To further expand, not only cost would scale per pid multiplies per open > fd, but to detect which of the fds are DRM I see these three options: > > 1) Open and parse fdinfo. > 2) Name based matching ie /dev/dri/.. something. > 3) Stat the symlink target and check for DRM major. stat with symlink following should be plenty fast. > All sound quite sub-optimal to me. > > Name based matching is probably the least evil on system resource usage > (Keeping the dentry cache too hot? Too many syscalls?), even though > fundamentally I don't it is the right approach. > > What happens with dup(2) is another question. We need benchmark numbers showing that on anything remotely realistic it's an actual problem. Until we've demonstrated it's a real problem we don't need to solve it. E.g. top with any sorting enabled also parses way more than it displays on every update. It seems to be doing Just Fine (tm). > Does anyone have any feedback on the /proc//gpu idea at all? When we know we have a problem to solve we can take a look at solutions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 6/8] drm/nouveau: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Note that this fixes an inconsistency: We've set the cap everywhere, but only nv50+ supports modifiers. Hence cc stable, but not further back then the patch from Paul. Cc: sta...@vger.kernel.org # v5.1 + Cc: Pekka Paalanen Signed-off-by: Daniel Vetter Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_display.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 14101bd2a0ff..929de41c281f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device *dev) dev->mode_config.preferred_depth = 24; dev->mode_config.prefer_shadow = 1; - dev->mode_config.allow_fb_modifiers = true; if (drm->client.device.info.chipset < 0x11) dev->mode_config.async_page_flip = false; -- 2.31.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
On Wed, Apr 21, 2021 at 09:01:00AM +0200, Christian König wrote: > Am 20.04.21 um 22:53 schrieb Daniel Vetter: > > On Tue, Apr 20, 2021 at 10:23 PM Felix Kuehling > > wrote: > > > > > > Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter: > > > > > > Whole series is Reviewed-by: Christian König > > > > > > > > > > > Thanks a lot. If I'm not mistaken, the patches at [1] need to go in > > > > > first. > > > > > So it could take a a bit until this lands. > > > > > > > > > > Otherwise, this series could go through the same tree as [1] if > > > > > nouveau and > > > > > vmwgfx devs don't mind. > > > > I would land it all through drm-misc-next. Maybe check with Alex on irc > > > > for an ack for merging that way, but I don't think this will cause > > > > issues > > > > against the amdgpu tree. Lots of ttm cleanup has landed this way already > > > > past few months. Otherwise you could create a small topic branch with > > > > these patches here and send that to Alex, and he can sort out the > > > > interaction with Felix' series. > > > > -Daniel > > > My patch series involved some pretty far-reaching changes in KFD > > > (renaming some variables in KFD and amdgpu, changing the KFD->amdgpu > > > interface). We already submitted other patches on top of it that have > > > dependencies on it. If we decide to deliver this through a different > > > tree and remove it from amd-staging-drm-next, there will be conflicts to > > > resolve when removing it from amd-staging-drm-next, and again the next > > > time you merge with amd-staging-drm-next. > > Ah then the usual way is for Alex to assemble a topic pull request > > (stable, non-rebasing) with those select patches, which then gets > > merged into drm-misc-next. Or we smash it all into amdgpu-next. Or we > > just wait until -rc2 when drm-next is back open for business. > > I need to double check, but if I'm not totally mistaken the changes in > question should already be in drm-next. > > But exactly that was the reason why I asked when the next backmerge from > drm-next into drm-misc-next is planned :) Best way to make that happen isn't to ask when it will happen, but tell drm-misc maintainers to do it and why (ideally with references to the commits you need). Also I tend to do those requests over irc. Backmerges are generally on demand, not on schedule. Hence you need to demand one :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
On Tue, Apr 20, 2021 at 10:23 PM Felix Kuehling wrote: > > > Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter: > >>> Whole series is Reviewed-by: Christian König > >> Thanks a lot. If I'm not mistaken, the patches at [1] need to go in first. > >> So it could take a a bit until this lands. > >> > >> Otherwise, this series could go through the same tree as [1] if nouveau and > >> vmwgfx devs don't mind. > > I would land it all through drm-misc-next. Maybe check with Alex on irc > > for an ack for merging that way, but I don't think this will cause issues > > against the amdgpu tree. Lots of ttm cleanup has landed this way already > > past few months. Otherwise you could create a small topic branch with > > these patches here and send that to Alex, and he can sort out the > > interaction with Felix' series. > > -Daniel > > My patch series involved some pretty far-reaching changes in KFD > (renaming some variables in KFD and amdgpu, changing the KFD->amdgpu > interface). We already submitted other patches on top of it that have > dependencies on it. If we decide to deliver this through a different > tree and remove it from amd-staging-drm-next, there will be conflicts to > resolve when removing it from amd-staging-drm-next, and again the next > time you merge with amd-staging-drm-next. Ah then the usual way is for Alex to assemble a topic pull request (stable, non-rebasing) with those select patches, which then gets merged into drm-misc-next. Or we smash it all into amdgpu-next. Or we just wait until -rc2 when drm-next is back open for business. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
d it all through drm-misc-next. Maybe check with Alex on irc for an ack for merging that way, but I don't think this will cause issues against the amdgpu tree. Lots of ttm cleanup has landed this way already past few months. Otherwise you could create a small topic branch with these patches here and send that to Alex, and he can sort out the interaction with Felix' series. -Daniel > > Best regards > Thomas > > [1] https://patchwork.freedesktop.org/series/88822/ > > > > > Thanks for the nice cleanup, > > Christian. > > > > > > > > Regards, > > > Christian. > > > > > > > + if (unlikely(ret != 0)) > > > > + goto out_unref; > > > > + > > > > + ret = ttm_bo_mmap_obj(vma, bo); > > > > + if (unlikely(ret != 0)) > > > > + goto out_unref; > > > > vma->vm_ops = &vmw_vm_ops; > > > > @@ -52,7 +96,13 @@ int vmw_mmap(struct file *filp, struct > > > > vm_area_struct *vma) > > > > if (!is_cow_mapping(vma->vm_flags)) > > > > vma->vm_flags = (vma->vm_flags & ~VM_MIXEDMAP) | VM_PFNMAP; > > > > + ttm_bo_put(bo); /* release extra ref taken > by > > > > ttm_bo_mmap_obj() */ > > > > + > > > > return 0; > > > > + > > > > +out_unref: > > > > + ttm_bo_put(bo); > > > > + return ret; > > > > } > > > > /* struct vmw_validation_mem callback */ > > > > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 1/7] drm/ttm: Don't override vm_ops callbacks, if set
On Thu, Apr 15, 2021 at 12:17:34PM +0200, Thomas Zimmermann wrote:
> Drivers may want to set their own callbacks for a VM area. Only set
> TTM's callbacks if the vm_ops field is clear.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index b31b18058965..bf4a213bc66c 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -534,7 +534,12 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup(struct
> ttm_device *bdev,
>
> static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
> vm_area_struct *vma)
> {
> - vma->vm_ops = &ttm_bo_vm_ops;
> + /*
> + * Drivers may want to override the vm_ops field. Otherwise we
> + * use TTM's default callbacks.
> + */
> + if (!vma->vm_ops)
> + vma->vm_ops = &ttm_bo_vm_ops;
>
> /*
>* Note: We're transferring the bo reference to
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 08/12] drm/nouveau: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Note that this fixes an inconsistency: We've set the cap everywhere, but only nv50+ supports modifiers. Hence cc stable, but not further back then the patch from Paul. Cc: sta...@vger.kernel.org # v5.1 + Cc: Pekka Paalanen Signed-off-by: Daniel Vetter Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_display.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 14101bd2a0ff..929de41c281f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device *dev) dev->mode_config.preferred_depth = 24; dev->mode_config.prefer_shadow = 1; - dev->mode_config.allow_fb_modifiers = true; if (drm->client.device.info.chipset < 0x11) dev->mode_config.async_page_flip = false; -- 2.31.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers
On Thu, Apr 08, 2021 at 01:38:59PM +0200, Thomas Zimmermann wrote: > Hi > > Am 08.04.21 um 13:19 schrieb Daniel Vetter: > > On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote: > > > Implement mmap via struct drm_gem_object_functions.mmap for amdgpu, > > > radeon and nouveau. This allows for using common DRM helpers for > > > the mmap-related callbacks in struct file_operations and struct > > > drm_driver. The drivers have their own vm_ops, which are now set > > > automatically by the DRM core functions. The code in each driver's > > > verify_access becomes part of the driver's new mmap implementation. > > > > Is there anything left in there which isn't already handled by the gem > > checks? Iirc there was some custom limit for ttm drivers once to allow > > co-existing with ums drivers, but that's never really been a thing since > > forever ... > > Vmwgfx does its own thing. radeon and amdgpu have some checks (userptr). But > it's all very small. The general tests will be in the GEM helpers. Ah userptr makes tons of sense. I think that should be rejected when creating the mmap offset, and then a WARN_ON to bail out. But that means we'd need to lift the basic userptr scaffolding to drm_gem_object. Which would make tons of sense imo (all the various semi-broken copypasta versions aren't great), but that's definitely for another time. -Daniel > > Best regards > Thomas > > > -Daniel > > > > > > > > With the GEM drivers converted, vmwgfx is the only user of > > > ttm_bo_mmap() and related infrastructure. So move everything into > > > vmwgfx and delete the rsp code from TTM. > > > > > > This touches several drivers. Preferably everything would be merged > > > at once via drm-misc-next. > > > > > > Thomas Zimmermann (8): > > >drm/ttm: Don't override vm_ops callbacks, if set > > >drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap() > > >drm/amdgpu: Implement mmap as GEM object function > > >drm/radeon: Implement mmap as GEM object function > > >drm/nouveau: Implement mmap as GEM object function > > >drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver > > >drm/vmwgfx: Inline vmw_verify_access() > > >drm/ttm: Remove ttm_bo_mmap() and friends > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 - > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 - > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++ > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 -- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 - > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71 - > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 - > > > drivers/gpu/drm/nouveau/nouveau_bo.c| 10 --- > > > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > > > drivers/gpu/drm/nouveau/nouveau_gem.c | 36 +++ > > > drivers/gpu/drm/nouveau/nouveau_ttm.c | 49 -- > > > drivers/gpu/drm/nouveau/nouveau_ttm.h | 1 - > > > drivers/gpu/drm/radeon/radeon_drv.c | 3 +- > > > drivers/gpu/drm/radeon/radeon_gem.c | 52 +++ > > > drivers/gpu/drm/radeon/radeon_ttm.c | 65 --- > > > drivers/gpu/drm/radeon/radeon_ttm.h | 1 - > > > drivers/gpu/drm/ttm/ttm_bo_vm.c | 60 ++--- > > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 --- > > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c| 51 ++- > > > include/drm/ttm/ttm_bo_api.h| 13 > > > include/drm/ttm/ttm_device.h| 15 - > > > 22 files changed, 212 insertions(+), 365 deletions(-) > > > > > > -- > > > 2.30.2 > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/4] drm: Generic dumb_map_offset for TTM-based drivers
On Thu, Apr 08, 2021 at 01:34:03PM +0200, Thomas Zimmermann wrote: > Hi > > Am 08.04.21 um 13:16 schrieb Daniel Vetter: > > On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote: > > > The implementation of drm_driver.dumb_map_offset is the same for several > > > TTM-based drivers. Provide a common function in GEM-TTM helpers. > > > > Out of curiosity, why does this not fit for radeon/amdgpu? > > These drivers perform additional permission checks in their implementations. > > But those checks are also part of the actual mmap code. I want to propose a > patch to use the generic drm_gem_ttm_map_offset in amdgpu/radeon, and then > rely on mmap to fail if necessary. It might result in a longer discussion, > so that's for another patchset. Ah cool, makes sense. -Daniel > > Best regards > Thomas > > > -Daniel > > > > > > > > Thomas Zimmermann (4): > > >drm/gem-ttm-helper: Provide helper for struct > > > drm_driver.dumb_map_offset > > >drm/vram-helper: Use drm_gem_ttm_dumb_map_offset() > > >drm/nouveau: Use drm_gem_ttm_dumb_map_offset() > > >drm/qxl: Use drm_gem_ttm_dumb_map_offset() > > > > > > drivers/gpu/drm/drm_gem_ttm_helper.c | 33 > > > drivers/gpu/drm/drm_gem_vram_helper.c | 48 --- > > > drivers/gpu/drm/nouveau/nouveau_display.c | 18 - > > > drivers/gpu/drm/nouveau/nouveau_display.h | 2 - > > > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > > > drivers/gpu/drm/qxl/qxl_drv.c | 3 +- > > > drivers/gpu/drm/qxl/qxl_drv.h | 3 -- > > > drivers/gpu/drm/qxl/qxl_dumb.c| 17 > > > drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +- > > > drivers/gpu/drm/qxl/qxl_object.h | 5 --- > > > include/drm/drm_gem_ttm_helper.h | 5 ++- > > > include/drm/drm_gem_vram_helper.h | 7 +--- > > > 12 files changed, 45 insertions(+), 103 deletions(-) > > > > > > -- > > > 2.30.2 > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers
On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote: > Implement mmap via struct drm_gem_object_functions.mmap for amdgpu, > radeon and nouveau. This allows for using common DRM helpers for > the mmap-related callbacks in struct file_operations and struct > drm_driver. The drivers have their own vm_ops, which are now set > automatically by the DRM core functions. The code in each driver's > verify_access becomes part of the driver's new mmap implementation. Is there anything left in there which isn't already handled by the gem checks? Iirc there was some custom limit for ttm drivers once to allow co-existing with ums drivers, but that's never really been a thing since forever ... -Daniel > > With the GEM drivers converted, vmwgfx is the only user of > ttm_bo_mmap() and related infrastructure. So move everything into > vmwgfx and delete the rsp code from TTM. > > This touches several drivers. Preferably everything would be merged > at once via drm-misc-next. > > Thomas Zimmermann (8): > drm/ttm: Don't override vm_ops callbacks, if set > drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap() > drm/amdgpu: Implement mmap as GEM object function > drm/radeon: Implement mmap as GEM object function > drm/nouveau: Implement mmap as GEM object function > drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver > drm/vmwgfx: Inline vmw_verify_access() > drm/ttm: Remove ttm_bo_mmap() and friends > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 - > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 - > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 -- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 - > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71 - > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 - > drivers/gpu/drm/nouveau/nouveau_bo.c| 10 --- > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > drivers/gpu/drm/nouveau/nouveau_gem.c | 36 +++ > drivers/gpu/drm/nouveau/nouveau_ttm.c | 49 -- > drivers/gpu/drm/nouveau/nouveau_ttm.h | 1 - > drivers/gpu/drm/radeon/radeon_drv.c | 3 +- > drivers/gpu/drm/radeon/radeon_gem.c | 52 +++ > drivers/gpu/drm/radeon/radeon_ttm.c | 65 --- > drivers/gpu/drm/radeon/radeon_ttm.h | 1 - > drivers/gpu/drm/ttm/ttm_bo_vm.c | 60 ++--- > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 --- > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c| 51 ++- > include/drm/ttm/ttm_bo_api.h | 13 > include/drm/ttm/ttm_device.h| 15 - > 22 files changed, 212 insertions(+), 365 deletions(-) > > -- > 2.30.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/4] drm: Generic dumb_map_offset for TTM-based drivers
On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote: > The implementation of drm_driver.dumb_map_offset is the same for several > TTM-based drivers. Provide a common function in GEM-TTM helpers. Out of curiosity, why does this not fit for radeon/amdgpu? -Daniel > > Thomas Zimmermann (4): > drm/gem-ttm-helper: Provide helper for struct > drm_driver.dumb_map_offset > drm/vram-helper: Use drm_gem_ttm_dumb_map_offset() > drm/nouveau: Use drm_gem_ttm_dumb_map_offset() > drm/qxl: Use drm_gem_ttm_dumb_map_offset() > > drivers/gpu/drm/drm_gem_ttm_helper.c | 33 > drivers/gpu/drm/drm_gem_vram_helper.c | 48 --- > drivers/gpu/drm/nouveau/nouveau_display.c | 18 - > drivers/gpu/drm/nouveau/nouveau_display.h | 2 - > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > drivers/gpu/drm/qxl/qxl_drv.c | 3 +- > drivers/gpu/drm/qxl/qxl_drv.h | 3 -- > drivers/gpu/drm/qxl/qxl_dumb.c| 17 > drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +- > drivers/gpu/drm/qxl/qxl_object.h | 5 --- > include/drm/drm_gem_ttm_helper.h | 5 ++- > include/drm/drm_gem_vram_helper.h | 7 +--- > 12 files changed, 45 insertions(+), 103 deletions(-) > > -- > 2.30.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH v2 00/20] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers
1 + > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 + > > drivers/gpu/drm/drm_dp_aux_dev.c | 6 + > > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 68 ++-- > > drivers/gpu/drm/drm_dp_helper.c | 181 + > > drivers/gpu/drm/drm_dp_mst_topology.c | 381 +- > > drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 + > > .../drm/i915/display/intel_dp_link_training.c | 6 +- > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- > > drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +- > > drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +- > > drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 +- > > drivers/gpu/drm/msm/edp/edp.h | 3 +- > > drivers/gpu/drm/msm/edp/edp_aux.c | 5 +- > > drivers/gpu/drm/msm/edp/edp_ctrl.c| 8 +- > > drivers/gpu/drm/nouveau/nouveau_connector.c | 27 +- > > drivers/gpu/drm/radeon/atombios_dp.c | 5 +- > > drivers/gpu/drm/tegra/dpaux.c | 12 +- > > drivers/gpu/drm/xlnx/zynqmp_dp.c | 5 +- > > include/drm/drm_dp_dual_mode_helper.h | 14 +- > > include/drm/drm_dp_helper.h | 61 +-- > > include/drm/drm_dp_mst_helper.h | 3 +- > > include/drm/drm_print.h | 20 +- > > 29 files changed, 478 insertions(+), 384 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [igt-dev] [PATCH i-g-t v2 1/2] tests/kms_cursor_crc: Probe kernel for cursor size support
; > > > vdisplay, DRM_FORMAT_XRGB, > > > > > > +LOCAL_DRM_FORMAT_MOD_NONE, > > > > > > &primary_fb)); > > > > > > > > > > > > - if (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid)) > > > > > > - return false; > > > > > > + igt_plane_set_fb(primary, &primary_fb); > > > > > > + igt_plane_set_fb(cursor, &data->fb); > > > > > > + igt_plane_set_size(cursor, w, h); > > > > > > + igt_fb_set_size(&data->fb, cursor, w, h); > > > > > > + > > > > > > + /* Test if the kernel supports the given cursor size or not > > > > > > */ > > > > > > + ret = igt_display_try_commit_atomic(display, > > > > > > + > > > > > > DRM_MODE_ATOMIC_TEST_ONLY | > > > > > > + > > > > > > DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > + NULL); > > > > > > > > > > Would be better to not depend on atomic. We have platforms > > > > > that don't expose it yet. > > > > > > > > Do you have any other ideas how we could probe for this then? it seems > > > > like > > > > the > > > > only alternative would be to add intel-specific checks to fix that, or > > > > add > > > > some > > > > ioctl for querying the minimum cursor size (which sounds preferable > > > > imo). > > > > would > > > > the latter work for you, or do you have another idea? > > > > > > Just do it for real instead of TEST_ONLY. > > > > ah-and it'll still fail in that case I assume? > > Yeah, should fail just the same if the driver doesn't like it. Doing the atomic TEST_ONLY first would be good, if atomic support exists, since it's faster. Doing modesets just to figure out whether we should test something is a bit expensive, best not to inflict on that on new machines. -Daniel > > -- > Ville Syrjälä > Intel > ___ > igt-dev mailing list > igt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/igt-dev -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND 00/53] Rid GPU from W=1 warnings
On Fri, Mar 19, 2021 at 08:24:07AM +, Lee Jones wrote: > On Thu, 18 Mar 2021, Daniel Vetter wrote: > > > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote: > > > > > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > > > > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > > > > That said, they were already signed off by Zack, so not sure > > > > > > > > what > > > > > > > > happened here. > > > > > > > > > > > > > > Yes, they were accepted at one point, then dropped without a > > > > > > > reason. > > > > > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back > > > > > > > out of > > > > > > > a previous one. > > > > > > > > > > > > They should show up in linux-next again. We merge patches for next > > > > > > merge > > > > > > window even during the current merge window, but need to make sure > > > > > > they > > > > > > don't pollute linux-next. Occasionally the cut off is wrong so > > > > > > patches > > > > > > show up, and then get pulled again. > > > > > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due > > > > > > to some > > > > > > confusion here. But your patches should all be in linux-next again > > > > > > (they > > > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > > > > > Sorry for the confusion here. > > > > > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > > > > > Thanks for the explanation Daniel > > > > > > > > After rebasing today, all of my GPU patches have remained. Would > > > > someone be kind enough to check that everything is still in order > > > > please? > > > > > > It's still broken somehow. I've kiced Maxime and Maarten again, > > > they're also on this thread. > > > > You're patches have made it into drm-next meanwhile, so they should > > show up in linux-next through that tree at least. Except if that one > > also has some trouble. > > Thanks for letting me know. > > I see some patches made it back in, others didn't. > > I'll resend the stragglers - bear with. The vmwgfx ones should all be back, the others I guess just werent ever applied. I'll vacuum them all up if you resend. Apologies for the wobbly ride. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND 00/53] Rid GPU from W=1 warnings
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote: > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > happened here. > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > a previous one. > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > window even during the current merge window, but need to make sure they > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > show up, and then get pulled again. > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to > > > > some > > > > confusion here. But your patches should all be in linux-next again (they > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > Sorry for the confusion here. > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > Thanks for the explanation Daniel > > > > After rebasing today, all of my GPU patches have remained. Would > > someone be kind enough to check that everything is still in order > > please? > > It's still broken somehow. I've kiced Maxime and Maarten again, > they're also on this thread. You're patches have made it into drm-next meanwhile, so they should show up in linux-next through that tree at least. Except if that one also has some trouble. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND 00/53] Rid GPU from W=1 warnings
On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > That said, they were already signed off by Zack, so not sure what > > > > > happened here. > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > a previous one. > > > > > > They should show up in linux-next again. We merge patches for next merge > > > window even during the current merge window, but need to make sure they > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > show up, and then get pulled again. > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > > confusion here. But your patches should all be in linux-next again (they > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > Sorry for the confusion here. > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > Thanks for the explanation Daniel > > After rebasing today, all of my GPU patches have remained. Would > someone be kind enough to check that everything is still in order > please? It's still broken somehow. I've kiced Maxime and Maarten again, they're also on this thread. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND 00/53] Rid GPU from W=1 warnings
On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > The vmwgfx ones look all good to me, so for > > 23-53: Reviewed-by: Roland Scheidegger > > That said, they were already signed off by Zack, so not sure what > > happened here. > > Yes, they were accepted at one point, then dropped without a reason. > > Since I rebased onto the latest -next, I had to pluck them back out of > a previous one. They should show up in linux-next again. We merge patches for next merge window even during the current merge window, but need to make sure they don't pollute linux-next. Occasionally the cut off is wrong so patches show up, and then get pulled again. Unfortunately especially the 5.12 merge cycle was very wobbly due to some confusion here. But your patches should all be in linux-next again (they are queued up for 5.13 in drm-misc-next, I checked that). Sorry for the confusion here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/pci: rework AGP dependency
> > -#if defined(CONFIG_AGP) || (defined(CONFIG_AGP_MODULE) && defined(MODULE))
> > #ifndef __NVKM_PCI_AGP_H__
> > #define __NVKM_PCI_AGP_H__
> >
> > +/* SPDX-License-Identifier: MIT */
> > +#include "priv.h"
> > +#if IS_ENABLED(CONFIG_AGP)
> > void nvkm_agp_ctor(struct nvkm_pci *);
> > void nvkm_agp_dtor(struct nvkm_pci *);
> > void nvkm_agp_preinit(struct nvkm_pci *);
> > int nvkm_agp_init(struct nvkm_pci *);
> > void nvkm_agp_fini(struct nvkm_pci *);
> > -#endif
> > #else
> > static inline void nvkm_agp_ctor(struct nvkm_pci *pci) {}
> > static inline void nvkm_agp_dtor(struct nvkm_pci *pci) {}
> > @@ -17,3 +16,5 @@ static inline void nvkm_agp_preinit(struct nvkm_pci *pci)
> > {}
> > static inline int nvkm_agp_init(struct nvkm_pci *pci) { return -ENOSYS; }
> > static inline void nvkm_agp_fini(struct nvkm_pci *pci) {}
> > #endif
> > +
> > +#endif
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/3] drm/ttm: constify static vm_operations_structs
On Wed, Feb 10, 2021 at 08:45:56AM +0100, Christian König wrote: > Reviewed-by: Christian König for the series. Smash it into -misc? -Daniel > > Am 10.02.21 um 00:48 schrieb Rikard Falkeborn: > > Constify a few static vm_operations_struct that are never modified. Their > > only usage is to assign their address to the vm_ops field in the > > vm_area_struct, which is a pointer to const vm_operations_struct. Make them > > const to allow the compiler to put them in read-only memory. > > > > With this series applied, all static struct vm_operations_struct in the > > kernel tree are const. > > > > Rikard Falkeborn (3): > >drm/amdgpu/ttm: constify static vm_operations_struct > >drm/radeon/ttm: constify static vm_operations_struct > >drm/nouveau/ttm: constify static vm_operations_struct > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- > > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> On 2/9/21 5:37 AM, Daniel Vetter wrote:
> > On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
> > >
> > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > > >
> > > > > Recent changes to pin_user_pages() prevent the creation of pinned
> > > > > pages in
> > > > > ZONE_MOVABLE. This series allows pinned pages to be created in
> > > ZONE_MOVABLE
> > > > > as attempts to migrate may fail which would be fatal to userspace.
> > > > >
> > > > > In this case migration of the pinned page is unnecessary as the page
> > > > > can
> > > be
> > > > > unpinned at anytime by having the driver revoke atomic permission as
> > > > > it
> > > > > does for the migrate_to_ram() callback. However a method of calling
> > > > > this
> > > > > when memory needs to be moved has yet to be resolved so any
> > > > > discussion is
> > > > > welcome.
> > > >
> > > > Why do we need to pin for gpu atomics? You still have the callback for
> > > > cpu faults, so you
> > > > can move the page as needed, and hence a long-term pin sounds like the
> > > > wrong approach.
> > >
> > > Technically a real long term unmoveable pin isn't required, because as
> > > you say
> > > the page can be moved as needed at any time. However I needed some way of
> > > stopping the CPU page from being freed once the userspace mappings for it
> > > had
> > > been removed. Obviously I could have just used get_page() but from the
> > > perspective of page migration the result is much the same as a pin - a
> > > page
> > > which can't be moved because of the extra refcount.
> >
> > long term pin vs short term page reference aren't fully fleshed out.
> > But the rule more or less is:
> > - short term page reference: _must_ get released in finite time for
> > migration and other things, either because you have a callback, or
> > because it's just for direct I/O, which will complete. This means
> > short term pins will delay migration, but not foul it complete
>
>
> GPU atomic operations to sysmem are hard to categorize, because because
> application
> programmers could easily write programs that do a long series of atomic
> operations.
> Such a program would be a little weird, but it's hard to rule out.
Yeah, but we can forcefully break this whenever we feel like by revoking
the page, moving it, and then reinstating the gpu pte again and let it
continue.
If that's no possible then what we need here instead is an mlock() type of
thing I think.
> > - long term pin: the page cannot be moved, all migration must fail.
> > Also this will have an impact on COW behaviour for fork (but not sure
> > where those patches are, John Hubbard will know).
>
>
> That would be Jason's commit 57efa1fe59576 ("mm/gup: prevent gup_fast from
> racing
> with COW during fork"), which is in linux-next 20201216.
Nice, thanks for the pointer.
>
>
> >
> > So I think for your use case here you want a) short term page
> > reference to make sure it doesn't disappear plus b) callback to make
> > sure migrate isn't blocked.
> >
> > Breaking ZONE_MOVEABLE with either allowing long term pins or failing
> > migrations because you don't release your short term page reference
> > isn't good.
> >
> > > The normal solution of registering an MMU notifier to unpin the page when
> > > it
> > > needs to be moved also doesn't work as the CPU page tables now point to
> > > the
> > > device-private page and hence the migration code won't call any invalidate
> > > notifiers for the CPU page.
> >
> > Yeah you need some other callback for migration on the page directly.
> > it's a bit awkward since there is one already for struct
> > address_space, but that's own by the address_space/page cache, not
> > HMM. So I think we need something else, maybe something for each
> > ZONE_DEVICE?
> >
>
> This direction sounds at least...possible. Using MMU notifiers instead of pins
> is definitely appealing. I'm not quite clear on the callback idea above, but
> overall it seems like taking advantage of the ZONE_DEVICE tracking of pages
> (without having to put anything additional in each struct page), could work.
>
> Additional note
Re: [Nouveau] [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 9, 2021 at 2:35 PM Jason Gunthorpe wrote: > > On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote: > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote: > > > > > > > > Recent changes to pin_user_pages() prevent the creation of pinned pages > > > > in > > > > ZONE_MOVABLE. This series allows pinned pages to be created in > > ZONE_MOVABLE > > > > as attempts to migrate may fail which would be fatal to userspace. > > > > > > > > In this case migration of the pinned page is unnecessary as the page can > > be > > > > unpinned at anytime by having the driver revoke atomic permission as it > > > > does for the migrate_to_ram() callback. However a method of calling this > > > > when memory needs to be moved has yet to be resolved so any discussion > > > > is > > > > welcome. > > > > > > Why do we need to pin for gpu atomics? You still have the callback for > > > cpu faults, so you > > > can move the page as needed, and hence a long-term pin sounds like the > > > wrong approach. > > > > Technically a real long term unmoveable pin isn't required, because as you > > say > > the page can be moved as needed at any time. However I needed some way of > > stopping the CPU page from being freed once the userspace mappings for it > > had > > been removed. > > The issue is you took the page out of the PTE it belongs to, which > makes it orphaned and unlocatable by the rest of the mm? > > Ideally this would leave the PTE in place so everything continues to > work, just disable CPU access to it. > > Maybe some kind of special swap entry? I probably should have read the patches more in detail, I was assuming the ZONE_DEVICE is only for vram. At least I thought the requirement for gpu atomics was that the page is in vram, but maybe I'm mixing up how this works on nvidia with how it works in other places. Iirc we had a long discussion about this at lpc19 that ended with the conclusion that we must be able to migrate, and sometimes migration is blocked. But the details ellude me now. Either way ZONE_DEVICE for not vram/device memory sounds wrong. Is that really going on here? -Daniel > > I also don't much like the use of ZONE_DEVICE here, that should only > be used for actual device memory, not as a temporary proxy for CPU > pages.. Having two struct pages refer to the same physical memory is > pretty ugly. > > > The normal solution of registering an MMU notifier to unpin the page when it > > needs to be moved also doesn't work as the CPU page tables now point to the > > device-private page and hence the migration code won't call any invalidate > > notifiers for the CPU page. > > The fact the page is lost from the MM seems to be the main issue here. > > > Yes, I would like to avoid the long term pin constraints as well if > > possible I > > just haven't found a solution yet. Are you suggesting it might be possible > > to > > add a callback in the page migration logic to specially deal with moving > > these > > pages? > > How would migration even find the page? > > Jason -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote: > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote: > > > > > > Recent changes to pin_user_pages() prevent the creation of pinned pages in > > > ZONE_MOVABLE. This series allows pinned pages to be created in > ZONE_MOVABLE > > > as attempts to migrate may fail which would be fatal to userspace. > > > > > > In this case migration of the pinned page is unnecessary as the page can > be > > > unpinned at anytime by having the driver revoke atomic permission as it > > > does for the migrate_to_ram() callback. However a method of calling this > > > when memory needs to be moved has yet to be resolved so any discussion is > > > welcome. > > > > Why do we need to pin for gpu atomics? You still have the callback for > > cpu faults, so you > > can move the page as needed, and hence a long-term pin sounds like the > > wrong approach. > > Technically a real long term unmoveable pin isn't required, because as you say > the page can be moved as needed at any time. However I needed some way of > stopping the CPU page from being freed once the userspace mappings for it had > been removed. Obviously I could have just used get_page() but from the > perspective of page migration the result is much the same as a pin - a page > which can't be moved because of the extra refcount. long term pin vs short term page reference aren't fully fleshed out. But the rule more or less is: - short term page reference: _must_ get released in finite time for migration and other things, either because you have a callback, or because it's just for direct I/O, which will complete. This means short term pins will delay migration, but not foul it complete - long term pin: the page cannot be moved, all migration must fail. Also this will have an impact on COW behaviour for fork (but not sure where those patches are, John Hubbard will know). So I think for your use case here you want a) short term page reference to make sure it doesn't disappear plus b) callback to make sure migrate isn't blocked. Breaking ZONE_MOVEABLE with either allowing long term pins or failing migrations because you don't release your short term page reference isn't good. > The normal solution of registering an MMU notifier to unpin the page when it > needs to be moved also doesn't work as the CPU page tables now point to the > device-private page and hence the migration code won't call any invalidate > notifiers for the CPU page. Yeah you need some other callback for migration on the page directly. it's a bit awkward since there is one already for struct address_space, but that's own by the address_space/page cache, not HMM. So I think we need something else, maybe something for each ZONE_DEVICE? > > That would avoid all the hacking around long term pin constraints, because > > for real unmoveable long term pinned memory we really want to have all > > these checks. So I think we might be missing some other callbacks to be > > able to move these pages, instead of abusing longterm pins for lack of > > better tools. > > Yes, I would like to avoid the long term pin constraints as well if possible I > just haven't found a solution yet. Are you suggesting it might be possible to > add a callback in the page migration logic to specially deal with moving these > pages? s/possible/need to type some code to address it/ I think. But also I'm not much of an expert on this, I've only just started learning how this all fits together coming from the gpu side. There's a _lot_ of finesse involved. Cheers, Daniel > > Thanks, Alistair > > > Cheers, Daniel > > > > > > > > > > > > Alistair Popple (9): > > > mm/migrate.c: Always allow device private pages to migrate > > > mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup() > > > mm/migrate: Add a unmap and pin migration mode > > > Documentation: Add unmap and pin to HMM > > > hmm-tests: Add test for unmap and pin > > > nouveau/dmem: Only map migrating pages > > > nouveau/svm: Refactor nouveau_range_fault > > > nouveau/dmem: Add support for multiple page types > > > nouveau/svm: Implement atomic SVM access > > > > > > Documentation/vm/hmm.rst | 22 +- > > > arch/powerpc/kvm/book3s_hv_uvmem.c| 4 +- > > > drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + > > > drivers/gpu/drm/nouveau/nouveau_dmem.c| 190 +++--- > > > drivers/gpu/drm/nouveau/nouveau_dmem.h| 9 + > > > drivers/gpu/drm
Re: [Nouveau] [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 09, 2021 at 12:07:13PM +1100, Alistair Popple wrote: > This series adds support to Nouveau for atomic memory operations on OpenCL > shared virtual memory (SVM). This is achieved using the atomic PTE bits on > the GPU to only permit atomic operations to system memory when a page is > not mapped in userspace on the CPU. > > This is implemented by adding a mode to migrate_vma_pages() which unmaps > and isolates existing pages from the CPU and pins them. The original > userspace page table entries are migrated to point to device private pages > allocated by the driver. This allows the driver to enable GPU atomic access > to the page as it will receive a callback when CPU userspace needs to > access it. > > In response to this callback the driver revokes the atomic access > permission from the GPU and migrates entries to point back to the original > page. The original page is unpinned as part of the migration operation > which also returns it to the LRU. > > Patch 3 contains the bulk of the memory management changes to implement > unmap and pin. > > Patches 6-9 extend Nouveau to use the new mode to allow system wide atomics > for OpenCL SVM to be implemented on Nouveau. > > This has been tested using the latest upstream Mesa userspace with a simple > OpenCL test program which checks the results of atomic GPU operations on a > buffer whilst also writing to the same buffer from the CPU. > > Problems yet to be addressed: > > Recent changes to pin_user_pages() prevent the creation of pinned pages in > ZONE_MOVABLE. This series allows pinned pages to be created in ZONE_MOVABLE > as attempts to migrate may fail which would be fatal to userspace. > > In this case migration of the pinned page is unnecessary as the page can be > unpinned at anytime by having the driver revoke atomic permission as it > does for the migrate_to_ram() callback. However a method of calling this > when memory needs to be moved has yet to be resolved so any discussion is > welcome. Why do we need to pin for gpu atomics? You still have the callback for cpu faults, so you can move the page as needed, and hence a long-term pin sounds like the wrong approach. That would avoid all the hacking around long term pin constraints, because for real unmoveable long term pinned memory we really want to have all these checks. So I think we might be missing some other callbacks to be able to move these pages, instead of abusing longterm pins for lack of better tools. Cheers, Daniel > > Alistair Popple (9): > mm/migrate.c: Always allow device private pages to migrate > mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup() > mm/migrate: Add a unmap and pin migration mode > Documentation: Add unmap and pin to HMM > hmm-tests: Add test for unmap and pin > nouveau/dmem: Only map migrating pages > nouveau/svm: Refactor nouveau_range_fault > nouveau/dmem: Add support for multiple page types > nouveau/svm: Implement atomic SVM access > > Documentation/vm/hmm.rst | 22 +- > arch/powerpc/kvm/book3s_hv_uvmem.c| 4 +- > drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + > drivers/gpu/drm/nouveau/nouveau_dmem.c| 190 +++--- > drivers/gpu/drm/nouveau/nouveau_dmem.h| 9 + > drivers/gpu/drm/nouveau/nouveau_svm.c | 148 +++--- > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + > .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 + > include/linux/migrate.h | 2 + > include/linux/migrate_mode.h | 1 + > lib/test_hmm.c| 109 -- > lib/test_hmm_uapi.h | 1 + > mm/migrate.c | 82 +--- > tools/testing/selftests/vm/hmm-tests.c| 49 + > 14 files changed, 524 insertions(+), 101 deletions(-) > > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote: > On Mon, 18 Jan 2021, Daniel Vetter wrote: > > > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > > > > > > > On Jan 15, 2021, at 13:15, Lee Jones wrote: > > > > > > > > This set is part of a larger effort attempting to clean-up W=1 > > > > kernel builds, which are currently overwhelmingly riddled with > > > > niggly little warnings. > > > > > > > > Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > > > > > > Thanks! For all the vmwgfx bits: > > > Reviewed-by: Zack Rusin > > > > Ok I merged everything except vmwgfx (that's for Zack) and i915/nouveau > > (those generally go through other trees, pls holler if they're stuck). > > Thanks Daniel, you're a superstar! > > So Zack will take the vmwgfx parts? Despite providing a R-b? I only merge stuff that's defacto abandoned already. Everything else I try to offload to whomever actually cares :-) -Daniel > > > Note that we have some build issue on some of the configs sfr uses, so drm > > trees are still stuck on old versions in linux-next. Hopefully should get > > resolved soon, the bugfix is in some subtree I've heard. > > No worries. Thanks for letting me know. > > -- > Lee Jones [李琼斯] > Senior Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > > > On Jan 15, 2021, at 13:15, Lee Jones wrote: > > > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > > Thanks! For all the vmwgfx bits: > Reviewed-by: Zack Rusin Can you pls push them to drm-misc-next? I'm planning to go pull in all the other patches later today that belong into drm-misc-next, but some patch monkey help would be really great :-) Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > > > On Jan 15, 2021, at 13:15, Lee Jones wrote: > > > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > > Thanks! For all the vmwgfx bits: > Reviewed-by: Zack Rusin Ok I merged everything except vmwgfx (that's for Zack) and i915/nouveau (those generally go through other trees, pls holler if they're stuck). Note that we have some build issue on some of the configs sfr uses, so drm trees are still stuck on old versions in linux-next. Hopefully should get resolved soon, the bugfix is in some subtree I've heard. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 2/8] drm/amdgpu: Remove references to struct drm_device.pdev
turn -EINVAL;
> >> @@ -627,7 +627,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev,
> >> void *data,
> >> if (args->va_address >= AMDGPU_GMC_HOLE_START &&
> >> args->va_address < AMDGPU_GMC_HOLE_END) {
> >> -dev_dbg(&dev->pdev->dev,
> >> +dev_dbg(dev->dev,
> >> "va_address 0x%LX is in VA hole 0x%LX-0x%LX\n",
> >> args->va_address, AMDGPU_GMC_HOLE_START,
> >> AMDGPU_GMC_HOLE_END);
> >> @@ -639,14 +639,14 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev,
> >> void *data,
> >> vm_size = adev->vm_manager.max_pfn * AMDGPU_GPU_PAGE_SIZE;
> >> vm_size -= AMDGPU_VA_RESERVED_SIZE;
> >> if (args->va_address + args->map_size > vm_size) {
> >> -dev_dbg(&dev->pdev->dev,
> >> +dev_dbg(dev->dev,
> >> "va_address 0x%llx is in top reserved area 0x%llx\n",
> >> args->va_address + args->map_size, vm_size);
> >> return -EINVAL;
> >> }
> >> if ((args->flags & ~valid_flags) && (args->flags & ~prt_flags)) {
> >> -dev_dbg(&dev->pdev->dev, "invalid flags combination 0x%08X\n",
> >> +dev_dbg(dev->dev, "invalid flags combination 0x%08X\n",
> >> args->flags);
> >> return -EINVAL;
> >> }
> >> @@ -658,7 +658,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev,
> >> void *data,
> >> case AMDGPU_VA_OP_REPLACE:
> >> break;
> >> default:
> >> -dev_dbg(&dev->pdev->dev, "unsupported operation %d\n",
> >> +dev_dbg(dev->dev, "unsupported operation %d\n",
> >> args->operation);
> >> return -EINVAL;
> >> }
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> >> index 47cad23a6b9e..bca45a15 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> >> @@ -176,7 +176,7 @@ struct amdgpu_i2c_chan *amdgpu_i2c_create(struct
> >> drm_device *dev,
> >> i2c->rec = *rec;
> >> i2c->adapter.owner = THIS_MODULE;
> >> i2c->adapter.class = I2C_CLASS_DDC;
> >> -i2c->adapter.dev.parent = &dev->pdev->dev;
> >> +i2c->adapter.dev.parent = dev->dev;
> >> i2c->dev = dev;
> >> i2c_set_adapdata(&i2c->adapter, i2c);
> >> mutex_init(&i2c->mutex);
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> index b16b32797624..3c37cf1ae8b7 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> @@ -142,7 +142,7 @@ int amdgpu_driver_load_kms(struct amdgpu_device
> >> *adev, unsigned long flags)
> >> (amdgpu_is_atpx_hybrid() ||
> >>amdgpu_has_atpx_dgpu_power_cntl()) &&
> >> ((flags & AMD_IS_APU) == 0) &&
> >> -!pci_is_thunderbolt_attached(dev->pdev))
> >> +!pci_is_thunderbolt_attached(to_pci_dev(dev->dev)))
> >> flags |= AMD_IS_PX;
> >> parent = pci_upstream_bridge(adev->pdev);
> >> @@ -156,7 +156,7 @@ int amdgpu_driver_load_kms(struct amdgpu_device
> >> *adev, unsigned long flags)
> >>*/
> >> r = amdgpu_device_init(adev, flags);
> >> if (r) {
> >> -dev_err(&dev->pdev->dev, "Fatal error during GPU init\n");
> >> +dev_err(dev->dev, "Fatal error during GPU init\n");
> >> goto out;
> >> }
> >> @@ -199,7 +199,7 @@ int amdgpu_driver_load_kms(struct amdgpu_device
> >> *adev, unsigned long flags)
> >> acpi_status = amdgpu_acpi_init(adev);
> >> if (acpi_status)
> >> -dev_dbg(&dev->pdev->dev, "Error during ACPI methods call\n");
> >> +dev_dbg(dev->dev, "Error during ACPI methods call\n");
> >> if (adev->runpm) {
> >> /* only need to skip on ATPX */
> >> @@ -735,10 +735,10 @@ int amdgpu_info_ioctl(struct drm_device *dev,
> >> void *data, struct drm_file *filp)
> >> if (!dev_info)
> >> return -ENOMEM;
> >> -dev_info->device_id = dev->pdev->device;
> >> +dev_info->device_id = adev->pdev->device;
> >> dev_info->chip_rev = adev->rev_id;
> >> dev_info->external_rev = adev->external_rev_id;
> >> -dev_info->pci_rev = dev->pdev->revision;
> >> +dev_info->pci_rev = adev->pdev->revision;
> >> dev_info->family = adev->family;
> >> dev_info->num_shader_engines =
> >> adev->gfx.config.max_shader_engines;
> >> dev_info->num_shader_arrays_per_engine =
> >> adev->gfx.config.max_sh_per_se;
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [kbuild-all] Re: [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
27; has no member named 'pdev'; did you mean 'dev'?
> > > > 1005 | pci_release_region(dev->pdev, 2);
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1007:28: error: 'struct
> > > > drm_device' has no member named 'pdev'; did you mean 'dev'?
> > > > 1007 | pci_release_regions(dev->pdev);
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function
> > > > 'vmw_driver_unload':
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1056:27: error: 'struct
> > > > drm_device' has no member named 'pdev'; did you mean 'dev'?
> > > > 1056 | pci_release_region(dev->pdev, 2);
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1058:28: error: 'struct
> > > > drm_device' has no member named 'pdev'; did you mean 'dev'?
> > > > 1058 | pci_release_regions(dev->pdev);
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_probe':
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1522:7: error: 'struct
> > > > drm_device' has no member named 'pdev'; did you mean 'dev'?
> > > > 1522 | dev->pdev = pdev;
> > > > | ^~~~
> > > > | dev
> > > > --
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: In function 'vmw_fb_init':
> > > > > > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:641:42: error:
> > > > > > 'struct drm_device' has no member named 'pdev'; did you
> > > > > > mean 'dev'?
> > > > 641 | struct device *device = &vmw_priv->dev->pdev->dev;
> > > > | ^~~~
> > > > | dev
> > > > In file included from drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:35:
> > > > At top level:
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:256:23: warning:
> > > > 'vmw_cursor_plane_formats' defined but not used
> > > > [-Wunused-const-variable=]
> > > > 256 | static const uint32_t vmw_cursor_plane_formats[] = {
> > > > | ^~~~
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:248:23: warning:
> > > > 'vmw_primary_plane_formats' defined but not used
> > > > [-Wunused-const-variable=]
> > > > 248 | static const uint32_t vmw_primary_plane_formats[] = {
> > > > | ^
> > > > --
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function
> > > > 'vmw_cmdbuf_set_pool_size':
> > > > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:1233:48: error:
> > > > > > 'struct drm_device' has no member named 'pdev'; did you
> > > > > > mean 'dev'?
> > > > 1233 | man->map =
> > > > dma_alloc_coherent(&dev_priv->dev->pdev->dev, size,
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function
> > > > 'vmw_cmdbuf_man_create':
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:1316:28: error:
> > > > 'struct drm_device' has no member named 'pdev'; did you mean
> > > > 'dev'?
> > > > 1316 | &dev_priv->dev->pdev->dev,
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:1325:22: error:
> > > > 'struct drm_device' has no member named 'pdev'; did you mean
> > > > 'dev'?
> > > > 1325 | &dev_priv->dev->pdev->dev,
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function
> > > > 'vmw_cmdbuf_remove_pool':
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:1390:42: error:
> > > > 'struct drm_device' has no member named 'pdev'; did you mean
> > > > 'dev'?
> > > > 1390 | dma_free_coherent(&man->dev_priv->dev->pdev->dev,
> > > > | ^~~~
> > > > | dev
> > > >
> > > >
> > > > vim +509 drivers/gpu/drm/gma500/oaktrail_device.c
> > > >
> > > > 1b082ccf5901108 Alan Cox 2011-11-03 503
> > > > 1b22edfd6efd02b Alan Cox 2011-11-29 504 static int
> > > > oaktrail_chip_setup(struct drm_device *dev)
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 505 {
> > > > 1b22edfd6efd02b Alan Cox 2011-11-29 506 struct
> > > > drm_psb_private *dev_priv = dev->dev_private;
> > > > 1b22edfd6efd02b Alan Cox 2011-11-29 507 int ret;
> > > > 1b22edfd6efd02b Alan Cox 2011-11-29 508
> > > > 9c0b6fcdc9faee5 Alan Cox 2012-05-11 @509 if
> > > > (pci_enable_msi(dev->pdev))
> > > > 9c0b6fcdc9faee5 Alan Cox 2012-05-11 510
> > > > dev_warn(dev->dev, "Enabling MSI failed!\n");
> > > > 9c0b6fcdc9faee5 Alan Cox 2012-05-11 511
> > > > 8512e0748729a49 Alan Cox 2012-05-11 512
> > > > dev_priv->regmap = oaktrail_regmap;
> > > > 8512e0748729a49 Alan Cox 2012-05-11 513
> > > > 1b22edfd6efd02b Alan Cox 2011-11-29 514 ret =
> > > > mid_chip_setup(dev);
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 515 if (ret < 0)
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 516 return ret;
> > > > 4086b1e2b19729e Kirill A. Shutemov 2012-05-03 517 if
> > > > (!dev_priv->has_gct) {
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 518 /*
> > > > Now pull the BIOS data */
> > > > d839ede47a56ff5 Alan Cox 2012-05-03 519
> > > > psb_intel_opregion_init(dev);
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 520
> > > > psb_intel_init_bios(dev);
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 521 }
> > > > 6528c897966c7d5 Patrik Jakobsson 2013-11-07 522
> > > > gma_intel_setup_gmbus(dev);
> > > > 5f503148efdda26 Alan Cox 2012-05-03 523
> > > > oaktrail_hdmi_setup(dev);
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 524 return 0;
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 525 }
> > > > aa0c45fdca0cff3 Alan Cox 2011-11-29 526
> > > >
> > > > ---
> > > > 0-DAY CI Kernel Test Service, Intel Corporation
> > > > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> > > >
> > >
> > >
> > > ___
> > > kbuild-all mailing list -- kbuild-...@lists.01.org
> > > To unsubscribe send an email to kbuild-all-le...@lists.01.org
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: > >>> > >>> Hi > >>> > >>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >>>> Hi > >>>> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>>>> > >>>>> > >>>>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann > >>>>>> wrote: > >>>>>> > >>>>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > >>>>>> drm_device.dev. No functional changes. > >>>>>> > >>>>>> Signed-off-by: Thomas Zimmermann > >>>>>> Cc: Roland Scheidegger > >>>>>> --- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>>>> > >>>>> Reviewed-by: Zack Rusin > >>>> Could you add this patch to the vmwgfx tree? > >>> > >>> AMD devs indicated that they'd prefer to merge the patchset trough > >>> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through > >>> drm-misc-next as well. > >> > >> Sounds good. I’ll make sure to rebase our latest patch set on top of it > >> when it’s in. Thanks! > > > > btw if you want to avoid multi-tree coordination headaches, we can > > also manage vmwgfx in drm-misc and give you & Roland commit rights > > there. Up to you. There is some scripting involved for now (but I hope > > whenever we move to gitlab we could do the checks server-side): > > I’d be happy to take you up on that. I would like to move a lot more of > our development into public repos and reducing the burden of maintaining > multiple trees would help. Is there a lot of changes to drm core that > doesn’t go through drm-misc? Or alternatively is drm-misc often pulling > from Linus’ master? I’m trying to figure out how much would our need to > rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes > because that would also allow me to point some internal testing > infrastructure at it as well. I think nowadays pretty much all the cross-driver work lands through drm-misc. Exception is just new stuff that's only used by a single driver. For testing there's also drm-tip, which tries to pull it all together (but you might still want to point your CI at branches). Also note that drm-misc-next doesn't have a merge window freeze period (with have the drm-misc-next-fixes branch during that time for merge window fixes), so you can treat it like a main development branch like e.g. in mesa, with the -fixes branches as the release branches. Only difference is that we don't cherry pick patches from the main branch to the release branches (at least not as the normal flow). If you do need a backmerge for patches from Linus to drm-misc-next because of some feature work (or conflicts with other stuff in general) drm-misc maintainers do that. Usually happens every few weeks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > > > > > On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: > > > > Hi > > > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >> Hi > >> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>> > >>> > >>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann wrote: > >>>> > >>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > >>>> drm_device.dev. No functional changes. > >>>> > >>>> Signed-off-by: Thomas Zimmermann > >>>> Cc: Roland Scheidegger > >>>> --- > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +- > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>> > >>> Reviewed-by: Zack Rusin > >> Could you add this patch to the vmwgfx tree? > > > > AMD devs indicated that they'd prefer to merge the patchset trough > > drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through > > drm-misc-next as well. > > Sounds good. I’ll make sure to rebase our latest patch set on top of it when > it’s in. Thanks! btw if you want to avoid multi-tree coordination headaches, we can also manage vmwgfx in drm-misc and give you & Roland commit rights there. Up to you. There is some scripting involved for now (but I hope whenever we move to gitlab we could do the checks server-side): https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH RESEND] drm/nouveau: Drop mutex_lock_nested for atomic
On Fri, Nov 27, 2020 at 05:35:28PM +0100, Daniel Vetter wrote:
> Purely conjecture, but I think the original locking inversion with the
> legacy page flip code between flipping and ttm's bo move function
> shoudn't exist anymore with atomic: With atomic the bo pinning and
> actual modeset commit is completely separated in the code patsh.
>
> This annotation was originally added in
>
> commit 060810d7abaabcab282e062c595871d661561400
> Author: Ben Skeggs
> Date: Mon Jul 8 14:15:51 2013 +1000
>
> drm/nouveau: fix locking issues in page flipping paths
>
> due to
>
> commit b580c9e2b7ba5030a795aa2fb73b796523d65a78
> Author: Maarten Lankhorst
> Date: Thu Jun 27 13:48:18 2013 +0200
>
> drm/nouveau: make flipping lockdep safe
>
> Acked-by: Ben Skeggs
> Reviewed-by: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Ben Skeggs
> Cc: Dave Airlie
> Cc: nouveau@lists.freedesktop.org
I stuffed this one into drm-misc-next now.
-Daniel
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 1386b0fc1640..43069dd8b027 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -774,7 +774,10 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
> evict,
> return ret;
> }
>
> - mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
> + if (drm_drv_uses_atomic_modeset(drm->dev))
> + mutex_lock(&cli->mutex);
> + else
> + mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
> ret = nouveau_fence_sync(nouveau_bo(bo), chan, true,
> ctx->interruptible);
> if (ret == 0) {
> ret = drm->ttm.move(chan, bo, &bo->mem, new_reg);
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH RESEND] drm/nouveau: Drop mutex_lock_nested for atomic
Purely conjecture, but I think the original locking inversion with the
legacy page flip code between flipping and ttm's bo move function
shoudn't exist anymore with atomic: With atomic the bo pinning and
actual modeset commit is completely separated in the code patsh.
This annotation was originally added in
commit 060810d7abaabcab282e062c595871d661561400
Author: Ben Skeggs
Date: Mon Jul 8 14:15:51 2013 +1000
drm/nouveau: fix locking issues in page flipping paths
due to
commit b580c9e2b7ba5030a795aa2fb73b796523d65a78
Author: Maarten Lankhorst
Date: Thu Jun 27 13:48:18 2013 +0200
drm/nouveau: make flipping lockdep safe
Acked-by: Ben Skeggs
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 1386b0fc1640..43069dd8b027 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -774,7 +774,10 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict,
return ret;
}
- mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
+ if (drm_drv_uses_atomic_modeset(drm->dev))
+ mutex_lock(&cli->mutex);
+ else
+ mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
ret = nouveau_fence_sync(nouveau_bo(bo), chan, true,
ctx->interruptible);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, &bo->mem, new_reg);
--
2.29.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: fix relocations applying logic and a double-free
On Mon, Nov 23, 2020 at 10:51:25AM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 4:23 PM Matti Hamalainen wrote:
> >
> > Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
> > a logic-bug which results in the relocations not actually getting
> > applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is
> > never reached. This causes a regression with graphical corruption,
> > triggered when relocations need to be done (for example after a
> > suspend/resume cycle.)
> >
> > Fix by setting *apply_relocs value only if there were more than 0
> > relocations.
> >
> > Additionally, the never reached code had a leftover u_free() call,
> > which, after fixing the logic, now got called and resulted in a
> > double-free. Fix by removing one u_free(), moving the other
> > and adding check for errors.
> >
> > Cc: Daniel Vetter
> > Cc: Ben Skeggs
> > Cc: nouveau@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Matti Hamalainen
> > Fixes: 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl")
> > Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/11
>
> Link: is for the mailing list submission of the patch itself (to link
> the git log to the mailing list discussions), this should be
> References: or similar. Aside from this:
>
> Reviewed-by: Daniel Vetter
>
> Ben, I'm assuming you'll push this through your tree.
Ok Dave asked me to just push it into drm-misc-fixes.
Thanks for your patch!
-Daniel
> -Daniel
>
>
> > ---
> > drivers/gpu/drm/nouveau/nouveau_gem.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > index 549bc67feabb..c2051380d18c 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > @@ -558,8 +558,10 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel
> > *chan,
> > NV_PRINTK(err, cli, "validating bo list\n");
> > validate_fini(op, chan, NULL, NULL);
> > return ret;
> > + } else if (ret > 0) {
> > + *apply_relocs = true;
> > }
> > - *apply_relocs = ret;
> > +
> > return 0;
> > }
> >
> > @@ -662,7 +664,6 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
> > nouveau_bo_wr32(nvbo, r->reloc_bo_offset >> 2, data);
> > }
> >
> > - u_free(reloc);
> > return ret;
> > }
> >
> > @@ -872,9 +873,10 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
> > *data,
> > break;
> > }
> > }
> > - u_free(reloc);
> > }
> > out_prevalid:
> > + if (!IS_ERR(reloc))
> > + u_free(reloc);
> > u_free(bo);
> > u_free(push);
> >
> >
> > base-commit: 3494d58865ad4a47611dbb427b214cc5227fa5eb
> > --
> > 2.29.2
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: fix relocations applying logic and a double-free
On Fri, Nov 20, 2020 at 4:23 PM Matti Hamalainen wrote:
>
> Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
> a logic-bug which results in the relocations not actually getting
> applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is
> never reached. This causes a regression with graphical corruption,
> triggered when relocations need to be done (for example after a
> suspend/resume cycle.)
>
> Fix by setting *apply_relocs value only if there were more than 0
> relocations.
>
> Additionally, the never reached code had a leftover u_free() call,
> which, after fixing the logic, now got called and resulted in a
> double-free. Fix by removing one u_free(), moving the other
> and adding check for errors.
>
> Cc: Daniel Vetter
> Cc: Ben Skeggs
> Cc: nouveau@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Matti Hamalainen
> Fixes: 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl")
> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/11
Link: is for the mailing list submission of the patch itself (to link
the git log to the mailing list discussions), this should be
References: or similar. Aside from this:
Reviewed-by: Daniel Vetter
Ben, I'm assuming you'll push this through your tree.
-Daniel
> ---
> drivers/gpu/drm/nouveau/nouveau_gem.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 549bc67feabb..c2051380d18c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -558,8 +558,10 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel
> *chan,
> NV_PRINTK(err, cli, "validating bo list\n");
> validate_fini(op, chan, NULL, NULL);
> return ret;
> + } else if (ret > 0) {
> + *apply_relocs = true;
> }
> - *apply_relocs = ret;
> +
> return 0;
> }
>
> @@ -662,7 +664,6 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
> nouveau_bo_wr32(nvbo, r->reloc_bo_offset >> 2, data);
> }
>
> - u_free(reloc);
> return ret;
> }
>
> @@ -872,9 +873,10 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
> *data,
> break;
> }
> }
> - u_free(reloc);
> }
> out_prevalid:
> + if (!IS_ERR(reloc))
> + u_free(reloc);
> u_free(bo);
> u_free(push);
>
>
> base-commit: 3494d58865ad4a47611dbb427b214cc5227fa5eb
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 21/42] drm/nouveau/nvkm/core/firmware: Fix formatting, provide missing param description
On Mon, Nov 16, 2020 at 05:40:51PM +, Lee Jones wrote: > ... and demote non-conformant kernel-doc header. > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'subdev' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'fwname' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'ver' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'fw' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:106: warning: Function > parameter or member 'fw' not described in 'nvkm_firmware_put' > > Cc: Ben Skeggs Ben fyi I smashed this into drm-misc-next, seemed trivial enough to not be a bother. -Daniel > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-de...@lists.freedesktop.org > Cc: nouveau@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > index 8b25367917ca0..ca1f8463cff51 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > @@ -58,9 +58,10 @@ nvkm_firmware_load_blob(const struct nvkm_subdev *subdev, > const char *base, > > /** > * nvkm_firmware_get - load firmware from the official nvidia/chip/ directory > - * @subdev subdevice that will use that firmware > - * @fwname name of firmware file to load > - * @fw firmware structure to load to > + * @subdev: subdevice that will use that firmware > + * @fwname: name of firmware file to load > + * @ver: firmware version to load > + * @fw: firmware structure to load to > * > * Use this function to load firmware files in the form > nvidia/chip/fwname.bin. > * Firmware files released by NVIDIA will always follow this format. > @@ -98,7 +99,7 @@ nvkm_firmware_get(const struct nvkm_subdev *subdev, const > char *fwname, int ver, > return -ENOENT; > } > > -/** > +/* > * nvkm_firmware_put - release firmware loaded with nvkm_firmware_get > */ > void > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
On Thu, Nov 05, 2020 at 11:37:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.11.20 um 11:07 schrieb Linus Walleij:
> > Overall I like this, just an inline question:
> >
> > On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann
> > wrote:
> >
> >> To do framebuffer updates, one needs memcpy from system memory and a
> >> pointer-increment function. Add both interfaces with documentation.
> >
> > (...)
> >> +/**
> >> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> >> + * @dst: The dma-buf mapping structure
> >> + * @src: The source buffer
> >> + * @len: The number of byte in src
> >> + *
> >> + * Copies data into a dma-buf mapping. The source buffer is in system
> >> + * memory. Depending on the buffer's location, the helper picks the
> >> correct
> >> + * method of accessing the memory.
> >> + */
> >> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const
> >> void *src, size_t len)
> >> +{
> >> + if (dst->is_iomem)
> >> + memcpy_toio(dst->vaddr_iomem, src, len);
> >> + else
> >> + memcpy(dst->vaddr, src, len);
> >> +}
> >
> > Are these going to be really big memcpy() operations?
>
> Individually, each could be a scanline, so a few KiB. (4 bytes *
> horizontal resolution). Updating a full framebuffer can sum up to
> several MiB.
>
> >
> > Some platforms have DMA offload engines that can perform memcpy(),They
> > could be
> > drivers/dma, include/linux/dmaengine.h
> > especially if the CPU doesn't really need to touch the contents
> > and flush caches etc.
> > An example exist in some MTD drivers that move large quantities of
> > data off flash memory like this:
> > drivers/mtd/nand/raw/cadence-nand-controller.c
> >
> > Notice that DMAengine and DMAbuf does not have much in common,
> > the names can be deceiving.
> >
> > The value of this varies with the system architecture. It is not just
> > a question about performance but also about power and the CPU
> > being able to do other stuff in parallel for large transfers. So *when*
> > to use this facility to accelerate memcpy() is a delicate question.
> >
> > What I'm after here is if these can be really big, do we want
> > (in the long run, not now) open up to the idea to slot in
> > hardware-accelerated memcpy() here?
>
> We currently use this functionality for the graphical framebuffer
> console that most DRM drivers provide. It's non-accelerated and slow,
> but this has not been much of a problem so far.
>
> Within DRM, we're more interested in removing console code from drivers
> and going for the generic implementation.
>
> Most of the graphics HW allocates framebuffers from video RAM, system
> memory or CMA pools and does not really need these memcpys. Only a few
> systems with small video RAM require a shadow buffer, which we flush
> into VRAM as needed. Those might benefit.
>
> OTOH, off-loading memcpys to hardware sounds reasonable if we can hide
> it from the DRM code. I think it all depends on how invasive that change
> would be.
I wouldn't, all the additional locks this would pull in sound like
nightmare. And when an oops happens, this might be the only thing that
manages to get the oops to the user.
Unless someone really starts caring about fbcon acceleration I really
wouldn't bother. Ok maybe it also matters for fbdev, but the problem is
that the page fault intercepting alone is already expensive, so the only
real solution if you care about performance in that case is to use kms
natively, and use a dirty rectangle flip (or the DIRTY syscall).
And in there drivers should (and do) use any dma engines they have to
upload the frames already.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 5/6] drm/: Constify struct drm_driver
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support. Subsequent patch will address this. - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. - arcpgu, because that is stuck behind a pending tiny-fication series from me. - legacy drivers, because legacy requires non-const drm_driver. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) v3: - Improve commit message (Sam) Acked-by: Sam Ravnborg Cc: kernel test robot Acked-by: Maxime Ripard Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Cc: Sam Ravnborg Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 7 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c| 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/stm/drv.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- drivers/gpu/drm/tegra/drm.c | 5 ++--- drivers/gpu/drm/tidss/tidss_drv.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c| 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c | 2 +- drivers/gpu/drm/tiny/ili9225.c | 2 +- drivers/gpu/drm/tiny/ili9341.c | 2 +- drivers/gpu/drm/tiny/ili9486.c | 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c | 2 +- drivers/gpu/drm/tiny/st7586.c| 2 +- drivers/gpu/drm/tiny/st7735r.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c| 2 +- drivers/gpu/drm/v3d/v3d_drv.c| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 63 files changed,
Re: [Nouveau] [PATCH] fbcon: Disable accelerated scrolling
On Sat, Oct 31, 2020 at 11:28 AM Geert Uytterhoeven
wrote:
>
> Hi Daniel,
>
> CC linux-fbdev
>
> Thanks for your patch!
>
> On Thu, 29 Oct 2020, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
>
> "git grep FBINFO_HWACCEL_COPYAREA" shows me there are 32 more drivers
> using acceleration under drivers/video/fbdev/.
>
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
>
> That sounds like a great argument to remove all hardware drivers from
> the kernel ;-)
fbdev is unmaintained, has no one volunteering to put in the work (and
there's huge amounts of work needed), and there's no test suite. No,
fbtest.c doesn't can't, that's not even close. We're not going to
delete everything in the kernel, but slowly sunsetting stuff that's
just costing and not bringing in up is a good idea.
> Seriously, how hard can it be to add "software-accelerated" acceleration
> hooks to drivers/video/fbdev/vfb.c, to enable syzbot to exercise the
> core acceleration code paths?
Just this one is 5 combinations, which means I'd need to convince
syzbot to test 5 different machine setups.
Plus we're still lacking a test suite, and judging from how much time
it took to get something basic going for kms, that's about 2 engineer
years of effort that no one is even close to willing to spend.
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling. The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
>
> Have you benchmarked the performance impact on traditional fbdev
> drivers?
There's still some acceleration if you have an image blit engine for
redrawing the screen. But the complexity is contained in the old
drivers that no one cares about.
For anything I have access to the difference is 0.
Also note that for anything remotely modern the fbcon acceleration
framework is pretty badly designed, because it does not allow
sufficient pipelining and queuing of operations. We've had an fbcon
acceleration prototype for i915 10 years ago or so, it's just not
worth the bother.
And again, no one is volunteering to create an fbcon accel framework
that doesn't just suck, despite that this has been discussed in
various places for years. I've done a summary of the sorry state of 2d
acceleration 2 years ago because it's come up so many times:
https://blog.ffwll.ch/2018/08/no-2d-in-drm.html Nothing at all
happened since then.
Reality is that fbdev is just there nowadays for Oops printing and
emergency usage, and it's plenty good enough for that. If there's
anyone who cares beyond that, they're most definitely not able to put
in time for upstream work.
-Daniel
> Thanks!
>
> > v2:
> > - Drop a few more unused local variables, somehow I missed the
> > compiler warnings (Sam)
> > - Fix typo in comment (Jiri)
> > - add a todo entry for the cleanup (Thomas)
> >
> > v3: Remove more unused variables (0day)
> >
> > Reviewed-by: Thomas Zimmermann
> > Reviewed-by: Greg Kroah-Hartman
> > Acked-by: Sam Ravnborg
> > Cc: Jiri Slaby
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Greg Kroah-Hartman
> > Cc: Linus Torvalds
> > Cc: Ben Skeggs
> > Cc: nouveau@lists.freedesktop.org
> > Cc: Tomi Valkei
[Nouveau] [PATCH 5/5] drm/: Constify struct drm_driver
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. - arcpgu, because that is stuck behind a pending tiny-fication series from me. - legacy drivers, because legacy requires non-const drm_driver. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) v3: - Improve commit message (Sam) Acked-by: Sam Ravnborg Cc: kernel test robot Acked-by: Maxime Ripard Signed-off-by: Daniel Vetter Cc: Sam Ravnborg Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 7 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c| 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/stm/drv.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- drivers/gpu/drm/tegra/drm.c | 5 ++--- drivers/gpu/drm/tidss/tidss_drv.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c| 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c | 2 +- drivers/gpu/drm/tiny/ili9225.c | 2 +- drivers/gpu/drm/tiny/ili9341.c | 2 +- drivers/gpu/drm/tiny/ili9486.c | 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c | 2 +- drivers/gpu/drm/tiny/st7586.c| 2 +- drivers/gpu/drm/tiny/st7735r.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c| 2 +- drivers/gpu/drm/v3d/v3d_drv.c| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 63 files changed, 75 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/dr
Re: [Nouveau] [PATCH] fbcon: Disable accelerated scrolling
On Fri, Oct 30, 2020 at 9:30 AM Tomi Valkeinen wrote:
>
> On 29/10/2020 15:22, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
> >
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
> >
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling. The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
> >
> > v2:
> > - Drop a few more unused local variables, somehow I missed the
> > compiler warnings (Sam)
> > - Fix typo in comment (Jiri)
> > - add a todo entry for the cleanup (Thomas)
> >
> > v3: Remove more unused variables (0day)
> >
> > Reviewed-by: Thomas Zimmermann
> > Reviewed-by: Greg Kroah-Hartman
> > Acked-by: Sam Ravnborg
> > Cc: Jiri Slaby
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Greg Kroah-Hartman
> > Cc: Linus Torvalds
> > Cc: Ben Skeggs
> > Cc: nouveau@lists.freedesktop.org
> > Cc: Tomi Valkeinen
> > Cc: Daniel Vetter
> > Cc: Jiri Slaby
> > Cc: "Gustavo A. R. Silva"
> > Cc: Tetsuo Handa
> > Cc: Peilin Ye
> > Cc: George Kennedy
> > Cc: Nathan Chancellor
> > Cc: Peter Rosin
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/todo.rst | 18 +
> > drivers/video/fbdev/core/fbcon.c | 45 ++--
> > 2 files changed, 26 insertions(+), 37 deletions(-)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 6b224ef14455..bec99341a904 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -277,6 +277,24 @@ Contact: Daniel Vetter, Noralf Tronnes
> >
> > Level: Advanced
> >
> > +Garbage collect fbdev scrolling acceleration
> > +
> > +
> > +Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
> > +SCROLL_REDRAW. There's a ton of code this will allow us to remove:
> > +- lots of code in fbcon.c
> > +- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be
> > called
> > + directly instead of the function table (with a switch on p->rotate)
> > +- fb_copyarea is unused after this, and can be deleted from all drivers
> > +
> > +Note that not all acceleration code can be deleted, since clearing and
> > cursor
> > +support is still accelerated, which might be good candidates for further
> > +deletion projects.
>
> Apparently omapdrm's accelerated panning has been broken for some time, and
> no one has noticed. It does:
>
> strcmp(fbi->fix.id, MODULE_NAME), which is a comparison of omapdrmdrmfb ==
> omapdrm and always fails.
>
> Fixing that, and applying this patch, things work fine (unaccelerated, of
> course). I did notice a
> single call to omap_fbdev_pan_display() when loading the drivers. This comes
> from fbcon_switch ->
> bit_update_start -> fb_pan_display. Maybe this is from the clearing you
> mention above?
The accel left is through fb_fillrect and fb_imageblt, plus there's
still fb_cursor (but not much use of that even in fbdev drivers).
I'm honestly not sure why there's the pan call in there, maybe just to
reset to default state in case an fbdev chardev user moved the origin
around. Aside from the accel code there's a call to this in
fbcon_switch and fbcon_modechanged, so I think it's just that.
-Daniel
>
> Reviewed-by: Tomi Valkeinen
>
> Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] fbcon: Disable accelerated scrolling
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb kernel console until userspace takes over, and Oops
printer for some emergencies. Looking at drm drivers and the basic
vesa/efi fbdev drivers shows that only 3 drivers support any kind of
acceleration:
- nouveau, seems to be enabled by default
- omapdrm, when a DMM remapper exists using remapper rewriting for
y/xpanning
- gma500, but that is getting deleted now for the GTT remapper trick,
and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
flag, so unused (and could be deleted already I think).
No other driver supportes accelerated fbcon. And fbcon is the only
user of this accel code (it's not exposed as uapi through ioctls),
which means we could garbage collect fairly enormous amounts of code
if we kill this.
Plus because syzbot only runs on virtual hardware, and none of the
drivers for that have acceleration, we'd remove a huge gap in testing.
And there's no other even remotely comprehensive testing aside from
syzbot.
This patch here just disables the acceleration code by always
redrawing when scrolling. The plan is that once this has been merged
for well over a year in released kernels, we can start to go around
and delete a lot of code.
v2:
- Drop a few more unused local variables, somehow I missed the
compiler warnings (Sam)
- Fix typo in comment (Jiri)
- add a todo entry for the cleanup (Thomas)
v3: Remove more unused variables (0day)
Reviewed-by: Thomas Zimmermann
Reviewed-by: Greg Kroah-Hartman
Acked-by: Sam Ravnborg
Cc: Jiri Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 18 +
drivers/video/fbdev/core/fbcon.c | 45 ++--
2 files changed, 26 insertions(+), 37 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 6b224ef14455..bec99341a904 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -277,6 +277,24 @@ Contact: Daniel Vetter, Noralf Tronnes
Level: Advanced
+Garbage collect fbdev scrolling acceleration
+
+
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:
+- lots of code in fbcon.c
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
+ directly instead of the function table (with a switch on p->rotate)
+- fb_copyarea is unused after this, and can be deleted from all drivers
+
+Note that not all acceleration code can be deleted, since clearing and cursor
+support is still accelerated, which might be good candidates for further
+deletion projects.
+
+Contact: Daniel Vetter
+
+Level: Intermediate
+
idr_init_base()
---
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index cef437817b0d..8d1ae973041a 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1033,7 +1033,7 @@ static void fbcon_init(struct vc_data *vc, int init)
struct vc_data *svc = *default_mode;
struct fbcon_display *t, *p = &fb_display[vc->vc_num];
int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
- int cap, ret;
+ int ret;
if (WARN_ON(info_idx == -1))
return;
@@ -1042,7 +1042,6 @@ static void fbcon_init(struct vc_data *vc, int init)
con2fb_map[vc->vc_num] = info_idx;
info = registered_fb[con2fb_map[vc->vc_num]];
- cap = info->flags;
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
logo_shown = FBCON_LOGO_DONTSHOW;
@@ -1147,11 +1146,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- if ((cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED))
- p->scrollmode = SCROLL_MOVE;
- else /* default to something safe */
- p->scrollmode = SCROLL_REDRAW;
+ /*
+* No more hw acceleration for fbcon.
+*
+* FIXME: Garbage collect all the now dead code after sufficient time
+* has passed.
+*/
+ p->scrollmode = SCROLL_REDRAW;
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1961,45 +1962,15 @@ static void updatescrollmode(str
[Nouveau] [PATCH 1/3] fbcon: Disable accelerated scrolling
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb kernel console until userspace takes over, and Oops
printer for some emergencies. Looking at drm drivers and the basic
vesa/efi fbdev drivers shows that only 3 drivers support any kind of
acceleration:
- nouveau, seems to be enabled by default
- omapdrm, when a DMM remapper exists using remapper rewriting for
y/xpanning
- gma500, but that is getting deleted now for the GTT remapper trick,
and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
flag, so unused (and could be deleted already I think).
No other driver supportes accelerated fbcon. And fbcon is the only
user of this accel code (it's not exposed as uapi through ioctls),
which means we could garbage collect fairly enormous amounts of code
if we kill this.
Plus because syzbot only runs on virtual hardware, and none of the
drivers for that have acceleration, we'd remove a huge gap in testing.
And there's no other even remotely comprehensive testing aside from
syzbot.
This patch here just disables the acceleration code by always
redrawing when scrolling. The plan is that once this has been merged
for well over a year in released kernels, we can start to go around
and delete a lot of code.
v2:
- Drop a few more unused local variables, somehow I missed the
compiler warnings (Sam)
- Fix typo in comment (Jiri)
- add a todo entry for the cleanup (Thomas)
Reviewed-by: Thomas Zimmermann
Reviewed-by: Greg Kroah-Hartman
Acked-by: Sam Ravnborg
Cc: Jiri Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 18 ++
drivers/video/fbdev/core/fbcon.c | 42 ++--
2 files changed, 25 insertions(+), 35 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 6b224ef14455..bec99341a904 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -277,6 +277,24 @@ Contact: Daniel Vetter, Noralf Tronnes
Level: Advanced
+Garbage collect fbdev scrolling acceleration
+
+
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:
+- lots of code in fbcon.c
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
+ directly instead of the function table (with a switch on p->rotate)
+- fb_copyarea is unused after this, and can be deleted from all drivers
+
+Note that not all acceleration code can be deleted, since clearing and cursor
+support is still accelerated, which might be good candidates for further
+deletion projects.
+
+Contact: Daniel Vetter
+
+Level: Intermediate
+
idr_init_base()
---
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index cef437817b0d..a68253485244 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1147,11 +1147,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- if ((cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED))
- p->scrollmode = SCROLL_MOVE;
- else /* default to something safe */
- p->scrollmode = SCROLL_REDRAW;
+ /*
+* No more hw acceleration for fbcon.
+*
+* FIXME: Garbage collect all the now dead code after sufficient time
+* has passed.
+*/
+ p->scrollmode = SCROLL_REDRAW;
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1961,45 +1963,15 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
- int cap = info->flags;
- u16 t = 0;
- int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
- info->fix.xpanstep);
- int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
- int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
- divides(ypan, vc->vc_font.height) && vyres > yres;
- int
Re: [Nouveau] [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 7:50 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
> >
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
> >
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling. The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
>
> See below for a warning fix.
>
> Some figures from trying to toss accel code out from a few fbdev drivers:
>
> drivers/video/fbdev/cirrusfb.c | 300
> +
> 1 file changed, 4 insertions(+), 296 deletions(-)
>
> drivers/video/fbdev/aty/radeon_accel.c | 174
> -
> drivers/video/fbdev/aty/radeon_base.c | 43 ++--
> drivers/video/fbdev/aty/radeon_pm.c| 7 --
> drivers/video/fbdev/aty/radeonfb.h | 3 -
> 4 files changed, 7 insertions(+), 220 deletions(-)
>
> This may open up the discussion if the right course of action would be
> to drop the drivers in favour of drm counterparts - but thats another
> story.
Yeah I think we can start deleting drivers for which we have drm
drivers which are mostly feature parity and see whether anyone pipes
up. There's always going to be the odd corner case (like apparently
the fbdev ati driver works better on some ppc machines than the drm
one).
The thing is, we can't delete the entire accel code with this, I think
only fb_copyarea goes away. The other hooks I think still have some
users.
-Daniel
>
> Sam
>
> > @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > - int cap = info->flags;
> > u16 t = 0;
> > int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > info->fix.xpanstep);
> > @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display
> > *p,
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > - divides(ypan, vc->vc_font.height) && vyres > yres;
> > - int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > - divides(ywrap, vc->vc_font.height) &&
> > - divides(vc->vc_font.height, vyres) &&
> > - divides(vc->vc_font.height, yres);
> > - int reading_fast = cap & FBINFO_READS_FAST;
> > - int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED);
> > - int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED);
>
> Some bot will likely tell you that this causes warnings.
> At least it did in my sparc64 build.
>
> Fix:
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 3989
Re: [Nouveau] [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 8:02 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
> >
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
> >
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling. The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
>
> Why wait a year? I'd say delete early, delete often. ;)
>
> >
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Greg Kroah-Hartman
> > Cc: Linus Torvalds
> > Cc: Ben Skeggs
> > Cc: nouveau@lists.freedesktop.org
> > Cc: Tomi Valkeinen
> > Cc: Daniel Vetter
> > Cc: Jiri Slaby
> > Cc: "Gustavo A. R. Silva"
> > Cc: Tetsuo Handa
> > Cc: Peilin Ye
> > Cc: George Kennedy
> > Cc: Nathan Chancellor
> > Cc: Peter Rosin
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/video/fbdev/core/fbcon.c | 38 ++--
> > 1 file changed, 7 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index cef437817b0d..d74ccbbb29bb 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -1147,11 +1147,13 @@ static void fbcon_init(struct vc_data *vc, int init)
> >
> > ops->graphics = 0;
> >
> > - if ((cap & FBINFO_HWACCEL_COPYAREA) &&
> > - !(cap & FBINFO_HWACCEL_DISABLED))
> > - p->scrollmode = SCROLL_MOVE;
> > - else /* default to something safe */
> > - p->scrollmode = SCROLL_REDRAW;
> > + /*
> > + * No more hw acceleration for fbcon.
> > + *
> > + * FIXME: Garabge collect all the now dead code after sufficient time
> > + * has passed.
> > + */
> > + p->scrollmode = SCROLL_REDRAW;
>
> I just grepped for scrollmode and there aren't many places that use it.
> Could you remove it as well?
Removing scrollmode will start the delete feast. In fbcon alone I
think we can drop half the code.
-Daniel
>
> In any case
>
> Reviewed-by: Thomas Zimmermann
>
> Best regards
> Thomas
>
> >
> > /*
> >* ++guenther: console.c:vc_allocate() relies on initializing
> > @@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > - int cap = info->flags;
> > u16 t = 0;
> > int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > info->fix.xpanstep);
> > @@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display
> > *p,
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > - int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > - divides(ypan, vc->vc_font.height) &
Re: [Nouveau] [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 5:45 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
> >
> > Now the problem is that most modern-ish drivers really only treat
> > fbcon as an dumb kernel console until userspace takes over, and Oops
> > printer for some emergencies. Looking at drm drivers and the basic
> > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > acceleration:
> >
> > - nouveau, seems to be enabled by default
> > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > y/xpanning
> > - gma500, but that is getting deleted now for the GTT remapper trick,
> > and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > flag, so unused (and could be deleted already I think).
> >
> > No other driver supportes accelerated fbcon. And fbcon is the only
> > user of this accel code (it's not exposed as uapi through ioctls),
> > which means we could garbage collect fairly enormous amounts of code
> > if we kill this.
> >
> > Plus because syzbot only runs on virtual hardware, and none of the
> > drivers for that have acceleration, we'd remove a huge gap in testing.
> > And there's no other even remotely comprehensive testing aside from
> > syzbot.
> >
> > This patch here just disables the acceleration code by always
> > redrawing when scrolling.
>
> So far I follow you - and agree.
> Acked-by: Sam Ravnborg
>
> > The plan is that once this has been merged
> > for well over a year in released kernels, we can start to go around
> > and delete a lot of code.
>
> Why wait one year? We deleted the scrollback code without any prior
> warning - which was fine. And acceleration support has less users
> so there should be no reason to wait.
>
> So unless there are good arguments that I miss then we should just
> delete the acceleration code outright.
If you grep for FBINFO_HWACCEL and related stuff, we could delete like
half the driver code, plus a ton of the related support code in fbcon
and fbdev core. It's going to be a lot of work, and I don't want to do
that and then have to back it out again. Compared to this the
softscrollback removal was nothing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] fbcon: Disable accelerated scrolling
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb kernel console until userspace takes over, and Oops
printer for some emergencies. Looking at drm drivers and the basic
vesa/efi fbdev drivers shows that only 3 drivers support any kind of
acceleration:
- nouveau, seems to be enabled by default
- omapdrm, when a DMM remapper exists using remapper rewriting for
y/xpanning
- gma500, but that is getting deleted now for the GTT remapper trick,
and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
flag, so unused (and could be deleted already I think).
No other driver supportes accelerated fbcon. And fbcon is the only
user of this accel code (it's not exposed as uapi through ioctls),
which means we could garbage collect fairly enormous amounts of code
if we kill this.
Plus because syzbot only runs on virtual hardware, and none of the
drivers for that have acceleration, we'd remove a huge gap in testing.
And there's no other even remotely comprehensive testing aside from
syzbot.
This patch here just disables the acceleration code by always
redrawing when scrolling. The plan is that once this has been merged
for well over a year in released kernels, we can start to go around
and delete a lot of code.
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
Signed-off-by: Daniel Vetter
---
drivers/video/fbdev/core/fbcon.c | 38 ++--
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index cef437817b0d..d74ccbbb29bb 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1147,11 +1147,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- if ((cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED))
- p->scrollmode = SCROLL_MOVE;
- else /* default to something safe */
- p->scrollmode = SCROLL_REDRAW;
+ /*
+* No more hw acceleration for fbcon.
+*
+* FIXME: Garabge collect all the now dead code after sufficient time
+* has passed.
+*/
+ p->scrollmode = SCROLL_REDRAW;
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1961,7 +1963,6 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
- int cap = info->flags;
u16 t = 0;
int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
info->fix.xpanstep);
@@ -1969,37 +1970,12 @@ static void updatescrollmode(struct fbcon_display *p,
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
- int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
- divides(ypan, vc->vc_font.height) && vyres > yres;
- int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
- divides(ywrap, vc->vc_font.height) &&
- divides(vc->vc_font.height, vyres) &&
- divides(vc->vc_font.height, yres);
- int reading_fast = cap & FBINFO_READS_FAST;
- int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED);
- int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
- !(cap & FBINFO_HWACCEL_DISABLED);
p->vrows = vyres/fh;
if (yres > (fh * (vc->vc_rows + 1)))
p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
if ((yres % fh) && (vyres % fh < yres % fh))
p->vrows--;
-
- if (good_wrap || good_pan) {
- if (reading_fast || fast_copyarea)
- p->scrollmode = good_wrap ?
- SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
- else
- p->scrollmode = good_wrap ? SCROLL_REDRAW :
- SCROLL_PAN_REDRAW;
- } else {
- if (reading_fast || (fast_copyarea && !fast_imageblit))
- p->scrollmode = SCROLL_MOVE;
- else
-
Re: [Nouveau] [PATCH 5/5] drm/: Constify struct drm_driver
On Mon, Oct 26, 2020 at 9:43 AM Thomas Zimmermann wrote: > > Hi > > Am 23.10.20 um 14:28 schrieb Daniel Vetter: > > Only the following drivers aren't converted: > > - amdgpu, because of the driver_feature mangling due to virt support > > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > > platforms where it's supported (i.e. again driver_feature mangling) > > - vc4, again because of driver_feature mangling > > - qxl, because the ioctl table is somewhere else and moving that is > > maybe a bit too much, hence the num_ioctls assignment prevents a > > const driver structure. > > > > Note that for armada I also went ahead and made the ioctl array const. > > > > Only cc'ing the driver people who've not been converted (everyone else > > is way too much). > > > > Signed-off-by: Daniel Vetter > > Cc: Dave Airlie > > Cc: Gerd Hoffmann > > Cc: virtualizat...@lists.linux-foundation.org > > Cc: Harry Wentland > > Cc: Leo Li > > Cc: Alex Deucher > > Cc: Christian König > > Cc: Eric Anholt > > Cc: Maxime Ripard > > Cc: Ben Skeggs > > Cc: nouveau@lists.freedesktop.org > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > drivers/gpu/drm/armada/armada_drv.c | 7 +++ > > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- > > drivers/gpu/drm/ast/ast_drv.c| 2 +- > > drivers/gpu/drm/ast/ast_drv.h| 2 +- > > drivers/gpu/drm/ast/ast_main.c | 2 +- > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > > drivers/gpu/drm/bochs/bochs_drv.c| 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- > > drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- > > drivers/gpu/drm/i915/i915_drv.c | 4 ++-- > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- > > drivers/gpu/drm/imx/imx-drm-core.c | 2 +- > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- > > drivers/gpu/drm/lima/lima_drv.c | 2 +- > > drivers/gpu/drm/mcde/mcde_drv.c | 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- > > drivers/gpu/drm/meson/meson_drv.c| 2 +- > > drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- > > drivers/gpu/drm/msm/msm_drv.c| 4 ++-- > > drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- > > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > > drivers/gpu/drm/pl111/pl111_drv.c| 2 +- > > drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- > > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > > drivers/gpu/drm/sti/sti_drv.c| 2 +- > > drivers/gpu/drm/stm/drv.c| 2 +- > > drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- > > drivers/gpu/drm/tegra/drm.c | 5 ++--- > > drivers/gpu/drm/tidss/tidss_drv.c| 2 +- > > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- > > drivers/gpu/drm/tiny/cirrus.c| 2 +- > > drivers/gpu/drm/tiny/gm12u320.c | 2 +- > > drivers/gpu/drm/tiny/hx8357d.c | 2 +- > > drivers/gpu/drm/tiny/ili9225.c | 2 +- > > drivers/gpu/drm/tiny/ili9341.c | 2 +- > > drivers/gpu/drm/tiny/ili9486.c | 2 +- > > drivers/gpu/drm/tiny/mi0283qt.c | 2 +- > > drivers/gpu/drm/tiny/repaper.c | 2 +- > > drivers/gpu/drm/tiny/st7586.c| 2 +- > > drivers/gpu/drm/tiny/st7735r.c | 2 +- > > drivers/gpu/drm/tve200/tve200_drv.c | 2 +- > > drivers/gpu/drm/udl/udl_drv.c| 2 +- >
Re: [Nouveau] [PATCH] drm/: Constify struct drm_driver
On Sun, Oct 25, 2020 at 11:23 PM Sam Ravnborg wrote: > > Hi Daniel. > > On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote: > > Only the following drivers aren't converted: > > - amdgpu, because of the driver_feature mangling due to virt support > > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > > platforms where it's supported (i.e. again driver_feature mangling) > > - vc4, again because of driver_feature mangling > > - qxl, because the ioctl table is somewhere else and moving that is > > maybe a bit too much, hence the num_ioctls assignment prevents a > > const driver structure. > My grepping turned up the following: > - The example in drm_drv needs to be updated > - legacy drivers, that are obviously not converted - but worth to > mention above > - arc is not converted and it is not legacy > Maybe you have it covered in your big arc conversion patch? Yeah I excluded that one because it's stuck behind my arcpgu tinification. I'll update the commit message to mention that with your other suggestions. -Daniel > > With the above fixed: > Acked-by: Sam Ravnborg > > > > Note that for armada I also went ahead and made the ioctl array const. > > > > Only cc'ing the driver people who've not been converted (everyone else > > is way too much). > > > > v2: Fix one misplaced const static, should be static const (0day) > > > > Cc: kernel test robot > > Acked-by: Maxime Ripard > > Signed-off-by: Daniel Vetter > > Cc: Dave Airlie > > Cc: Gerd Hoffmann > > Cc: virtualizat...@lists.linux-foundation.org > > Cc: Harry Wentland > > Cc: Leo Li > > Cc: Alex Deucher > > Cc: Christian König > > Cc: Eric Anholt > > Cc: Maxime Ripard > > Cc: Ben Skeggs > > Cc: nouveau@lists.freedesktop.org > > Signed-off-by: Daniel Vetter > > Hmm, so we have more than one Daniel in play here. > Both the Intel guy and the ffwll guy - looks funny. > > Sam > > > --- > > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > drivers/gpu/drm/armada/armada_drv.c | 7 +++ > > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- > > drivers/gpu/drm/ast/ast_drv.c| 2 +- > > drivers/gpu/drm/ast/ast_drv.h| 2 +- > > drivers/gpu/drm/ast/ast_main.c | 2 +- > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > > drivers/gpu/drm/bochs/bochs_drv.c| 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- > > drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- > > drivers/gpu/drm/i915/i915_drv.c | 4 ++-- > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- > > drivers/gpu/drm/imx/imx-drm-core.c | 2 +- > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- > > drivers/gpu/drm/lima/lima_drv.c | 2 +- > > drivers/gpu/drm/mcde/mcde_drv.c | 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- > > drivers/gpu/drm/meson/meson_drv.c| 2 +- > > drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- > > drivers/gpu/drm/msm/msm_drv.c| 4 ++-- > > drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- > > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > > drivers/gpu/drm/pl111/pl111_drv.c| 2 +- > > drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- > > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > > drivers/gpu/drm/sti/sti_drv.c| 2 +- > > drivers/gpu/drm/stm/drv.c| 2 +- > > drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- > > drivers/gpu/drm/tegra/drm.c | 5 ++--- > > drivers/gpu/drm/tidss/tidss_drv.c| 2 +- > > drivers/gpu
[Nouveau] [PATCH] drm/: Constify struct drm_driver
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) Cc: kernel test robot Acked-by: Maxime Ripard Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 7 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c| 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/stm/drv.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- drivers/gpu/drm/tegra/drm.c | 5 ++--- drivers/gpu/drm/tidss/tidss_drv.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c| 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c | 2 +- drivers/gpu/drm/tiny/ili9225.c | 2 +- drivers/gpu/drm/tiny/ili9341.c | 2 +- drivers/gpu/drm/tiny/ili9486.c | 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c | 2 +- drivers/gpu/drm/tiny/st7586.c| 2 +- drivers/gpu/drm/tiny/st7735r.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c| 2 +- drivers/gpu/drm/v3d/v3d_drv.c| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 63 files changed, 75 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index cc5b5915bc5e..d04008f3e31a 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_
Re: [Nouveau] [PATCH] drm/nouveau: Drop mutex_lock_nested for atomic
On Thu, Oct 01, 2020 at 08:46:59AM +1000, Ben Skeggs wrote:
> On Wed, 30 Sep 2020 at 19:37, Daniel Vetter wrote:
> >
> > On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote:
> > > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter
> > > wrote:
> > > >
> > > > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter
> > > > wrote:
> > > > >
> > > > > Ben, did you have a chance to look at this?
> > > >
> > > > Ping
> > > > -Daniel
> > > >
> > > > > On Mon, Aug 3, 2020 at 1:22 PM Maarten Lankhorst
> > > > > wrote:
> > > > > >
> > > > > > Op 02-08-2020 om 20:18 schreef Daniel Vetter:
> > > > > > > Purely conjecture, but I think the original locking inversion
> > > > > > > with the
> > > > > > > legacy page flip code between flipping and ttm's bo move function
> > > > > > > shoudn't exist anymore with atomic: With atomic the bo pinning and
> > > > > > > actual modeset commit is completely separated in the code patsh.
> > > > > > >
> > > > > > > This annotation was originally added in
> > > > > > >
> > > > > > > commit 060810d7abaabcab282e062c595871d661561400
> > > > > > > Author: Ben Skeggs
> > > > > > > Date: Mon Jul 8 14:15:51 2013 +1000
> > > > > > >
> > > > > > > drm/nouveau: fix locking issues in page flipping paths
> > > > > > >
> > > > > > > due to
> > > > > > >
> > > > > > > commit b580c9e2b7ba5030a795aa2fb73b796523d65a78
> > > > > > > Author: Maarten Lankhorst
> > > > > > > Date: Thu Jun 27 13:48:18 2013 +0200
> > > > > > >
> > > > > > > drm/nouveau: make flipping lockdep safe
> > > > > > >
> > > > > > > Signed-off-by: Daniel Vetter
> > > > > > > Cc: Maarten Lankhorst
> > > > > > > Cc: Ben Skeggs
> > > > > > > Cc: Dave Airlie
> > > > > > > Cc: nouveau@lists.freedesktop.org
> > > > > > > ---
> > > > > > > I might be totally wrong, so this definitely needs testing :-)
> > > > > > >
> > > > > > > Cheers, Daniel
> > > > > > > ---
> > > > > > > drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
> > > > > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > > > index 7806278dce57..a7b2a9bb0ffe 100644
> > > > > > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > > > @@ -776,7 +776,11 @@ nouveau_bo_move_m2mf(struct
> > > > > > > ttm_buffer_object *bo, int evict, bool intr,
> > > > > > > return ret;
> > > > > > > }
> > > > > > >
> > > > > > > - mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
> > > > > > > + if (drm_drv_uses_atomic_modeset(drm->dev))
> > > > > > > + mutex_lock(&cli->mutex);
> > > > > > > + else
> > > > > > > + mutex_lock_nested(&cli->mutex,
> > > > > > > SINGLE_DEPTH_NESTING);
> > > > > > > +
> > > > > > > ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
> > > > > > > if (ret == 0) {
> > > > > > > ret = drm->ttm.move(chan, bo, &bo->mem, new_reg);
> > > > > >
> > > > > > Well if you're certain it works now. :)
> > > > > >
> > > > > > Reviewed-by: Maarten Lankhorst
> > > Acked-by: Ben Skeggs
> >
> > Can you pull this in through your tree and maybe give it a spin just to
> > make sure? I don't really have nouveau hardware here.
> Yeah, I can do that easily enough.
Hi Ben,
I'm still hanging on this one, doesn't seem to have made it into drm-next.
Got lost or still somewhere in a queue?
Thanks, Daniel
>
> Ben.
>
> >
> > Also it's entirely stand-alone, I was simply reviewing all the
> > mutex_lock_nested we have in drm, and this one stuck out as probably not
> > necessary anymore, at least with atomic.
> >
> > I guess I can also just stuff it into drm-misc-next and if it blows up,
> > figure out what to do then :-)
> > -Daniel
> >
> > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
> > > > ___
> > > > Nouveau mailing list
> > > > Nouveau@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
