Use Architecture::Ampere, for example, instead of checking for
membership inside an exhaustive list of GPUs of that architecture.
Also, apply the new "use" multi-line format.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/gpu/nova-core/falcon/hal.rs | 15 ++++++++++-----
drivers/gpu/nova-core/fb/hal.rs | 20 +++++++++++++-------
drivers/gpu/nova-core/regs.rs | 5 ++++-
3 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/nova-core/falcon/hal.rs b/drivers/gpu/nova-core/falcon/hal.rs
index 7ba8ba856c72..08b97f593a8f 100644
--- a/drivers/gpu/nova-core/falcon/hal.rs
+++ b/drivers/gpu/nova-core/falcon/hal.rs
@@ -41,14 +41,19 @@ fn signature_reg_fuse_version(
pub(super) fn falcon_hal<E: FalconEngine + 'static>(
chipset: Chipset,
) -> Result<KBox<dyn FalconHal<E>>> {
- use Chipset::*;
+ use crate::gpu::Architecture;
- let hal = match chipset {
- GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
- | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
+ let hal = match chipset.arch() {
+ Architecture::Ampere
+ | Architecture::Hopper
+ | Architecture::Ada
+ | Architecture::Blackwell => {
KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
}
- _ => return Err(ENOTSUPP),
+ Architecture::Turing => {
+ // TODO: Add Turing falcon HAL support
+ return Err(ENOTSUPP);
+ }
};
Ok(hal)
diff --git a/drivers/gpu/nova-core/fb/hal.rs b/drivers/gpu/nova-core/fb/hal.rs
index 30fde2487d8b..dfa896dc8acf 100644
--- a/drivers/gpu/nova-core/fb/hal.rs
+++ b/drivers/gpu/nova-core/fb/hal.rs
@@ -27,12 +27,18 @@ pub(crate) trait FbHal {
/// Returns the HAL corresponding to `chipset`.
pub(super) fn fb_hal(chipset: Chipset) -> &'static dyn FbHal {
- use Chipset::*;
-
- match chipset {
- TU102 | TU104 | TU106 | TU117 | TU116 => tu102::TU102_HAL,
- GA100 => ga100::GA100_HAL,
- GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
- | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => ga102::GA102_HAL,
+ use crate::gpu::Architecture;
+
+ match chipset.arch() {
+ Architecture::Turing => tu102::TU102_HAL,
+ Architecture::Ampere => {
+ // GA100 has its own HAL, all other Ampere chips use GA102 HAL
+ if chipset == Chipset::GA100 {
+ ga100::GA100_HAL
+ } else {
+ ga102::GA102_HAL
+ }
+ }
+ Architecture::Hopper | Architecture::Ada | Architecture::Blackwell => ga102::GA102_HAL,
}
}
diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
index fcb319806391..deb9219ea126 100644
--- a/drivers/gpu/nova-core/regs.rs
+++ b/drivers/gpu/nova-core/regs.rs
@@ -11,7 +11,10 @@
DmaTrfCmdSize, FalconCoreRev, FalconCoreRevSubversion, FalconFbifMemType, FalconFbifTarget,
FalconModSelAlgo, FalconSecurityModel, PFalcon2Base, PFalconBase, PeregrineCoreSelect,
};
-use crate::gpu::{Architecture, Chipset};
+use crate::gpu::{
+ Architecture,
+ Chipset, //
+};
use crate::num::FromSafeCast;
use kernel::prelude::*;
--
2.51.2
On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
> -use crate::gpu::{Architecture, Chipset};
> +use crate::gpu::{
> + Architecture,
> + Chipset, //
> +};
I don't think this change should be part of this patch.
On 11/6/25 3:41 PM, Timur Tabi wrote:
> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>> -use crate::gpu::{Architecture, Chipset};
>> +use crate::gpu::{
>> + Architecture,
>> + Chipset, //
>> +};
>
> I don't think this change should be part of this patch.
I think it would be good to send a patch converting nova-core (and nova-drm) to
kernel vertical import style at once and then rebase other patches on top of that.
On 11/6/25 1:42 PM, Danilo Krummrich wrote:
> On 11/6/25 3:41 PM, Timur Tabi wrote:
>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>>> -use crate::gpu::{Architecture, Chipset};
>>> +use crate::gpu::{
>>> + Architecture,
>>> + Chipset, //
>>> +};
>>
>> I don't think this change should be part of this patch.
>
> I think it would be good to send a patch converting nova-core (and nova-drm) to
> kernel vertical import style at once and then rebase other patches on top of that.
Yes...thinking out loud, our fiercest merge/rebase conflicts lately
are not due to "use" statements, but other, more difficult items.
I'm thinking we can either do it, before or after the big pending
set of patches that have been posted so far, probably.
thanks,
John Hubbard
On 11/6/25 11:18 PM, John Hubbard wrote: > I'm thinking we can either do it, before or after the big pending > set of patches that have been posted so far, probably. I'd prefer doing it before, it ensures we have consistent style throughout the driver and gives the chance to cleanup unnecessary imports that are covered by prelude.
On 11/6/25 3:30 PM, Danilo Krummrich wrote: > On 11/6/25 11:18 PM, John Hubbard wrote: >> I'm thinking we can either do it, before or after the big pending >> set of patches that have been posted so far, probably. > > I'd prefer doing it before, it ensures we have consistent style throughout the > driver and gives the chance to cleanup unnecessary imports that are covered by > prelude. OK. I'll post something ASAP. thanks, -- John Hubbard
© 2016 - 2025 Red Hat, Inc.