From 094a478c0444aca60c92383c89b7f390b4c478a4 Mon Sep 17 00:00:00 2001
From: Douglas Raillard <douglas.raillard@arm.com>
Date: Wed, 16 Apr 2025 14:29:13 +0100
Subject: [PATCH 1/2] lisa._assets.kmodules.lisa: Fix pixel6 emeter sampling
 rate

FIX

Use 250Hz for hardware sampling rate as that value works across all
pixel devices from 6 to 9.

Also make the software sampling rate 1/8 of the hardware sampling rate,
as the hardware only produces a new sample every 8 periods.
---
 .../lisa/rust/lisakmod/src/features/pixel6.rs | 20 +++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/lisa/_assets/kmodules/lisa/rust/lisakmod/src/features/pixel6.rs b/lisa/_assets/kmodules/lisa/rust/lisakmod/src/features/pixel6.rs
index 4d990f9f5..c14df4e17 100644
--- a/lisa/_assets/kmodules/lisa/rust/lisakmod/src/features/pixel6.rs
+++ b/lisa/_assets/kmodules/lisa/rust/lisakmod/src/features/pixel6.rs
@@ -129,7 +129,7 @@ impl Device {
 struct DeviceConfig {
     id: DeviceId,
     folder: String,
-    hardware_sampling_rate_us: u64,
+    hardware_sampling_rate_hz: u64,
 }
 
 struct Pixel6EmeterConfig {
@@ -157,18 +157,19 @@ define_feature! {
                     .expect("Could not get service for WqFeature")
                     .wq();
 
-                let hardware_sampling_rate_us = 500;
+                // 250 Hz works for pixel 6, 7, 8 and 9 so we just use that.
+                let hardware_sampling_rate_hz = 250;
                 let config = Pixel6EmeterConfig {
                     devices: vec![
                         DeviceConfig {
                            id: 0,
                            folder: "/sys/bus/iio/devices/iio:device0/".into(),
-                           hardware_sampling_rate_us,
+                           hardware_sampling_rate_hz,
                         },
                         DeviceConfig {
                            id: 1,
                            folder: "/sys/bus/iio/devices/iio:device1/".into(),
-                           hardware_sampling_rate_us,
+                           hardware_sampling_rate_hz,
                         },
                     ]
                 };
@@ -187,7 +188,13 @@ define_feature! {
 
                     // Note that this is the hardware sampling rate. Software will only see an
                     // updated value every 8 hardware periods
-                    writeln!(rate_file, "{}", device_config.hardware_sampling_rate_us).map_err(|err| error!("Could not write to sampling_rate file: {err}"))?;
+                    let sampling_rate = device_config.hardware_sampling_rate_hz;
+                    let content = format!("{sampling_rate}\n");
+                    // Ensure we have a _single_ kernel_write() call. Otherwise, sysfs will be
+                    // confused by the partial write.
+                    rate_file.write(content.as_bytes())
+                        .map_err(|err| error!("Could not write \"{sampling_rate}\" to sampling_rate file: {err}"))?;
+                    rate_file.flush();
 
                     let device = Device {
                         value_file,
@@ -208,10 +215,11 @@ define_feature! {
                     }
                 }?;
 
+                let hardware_sampling_period_us = 1_000_000 / hardware_sampling_rate_hz;
                 // There is no point in setting this value to less than 8 times what is written in
                 // usec to the sampling_rate file, as the hardware will only expose a new value
                 // every 8 hardware periods.
-                let software_sampling_rate_us = hardware_sampling_rate_us / 8;
+                let software_sampling_rate_us = hardware_sampling_period_us * 8;
 
                 let work_item = wq::new_work_item!(wq, move |work| {
                     let process_device = |device: &mut Device| -> Result<(), Error> {
-- 
GitLab


From d724848d9db578ba4fb09c9dcd891641892ec29a Mon Sep 17 00:00:00 2001
From: Douglas Raillard <douglas.raillard@arm.com>
Date: Wed, 16 Apr 2025 15:33:06 +0100
Subject: [PATCH 2/2] lisa._assets.kmodules.lisa: Pass mod to filp_open()

FIX

Pass the "mode" parameter to filp_open(). So far it would not have had
any impact as we are never creating new files, but in the future it may
matter.
---
 lisa/_assets/kmodules/lisa/rust/lisakmod/src/runtime/fs.rs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisa/_assets/kmodules/lisa/rust/lisakmod/src/runtime/fs.rs b/lisa/_assets/kmodules/lisa/rust/lisakmod/src/runtime/fs.rs
index c39894709..327c556ca 100644
--- a/lisa/_assets/kmodules/lisa/rust/lisakmod/src/runtime/fs.rs
+++ b/lisa/_assets/kmodules/lisa/rust/lisakmod/src/runtime/fs.rs
@@ -42,7 +42,7 @@ pub struct File {
 }
 
 impl File {
-    pub fn open(path: &str, flags: OpenFlags, _mode: u32) -> Result<File, Error> {
+    pub fn open(path: &str, flags: OpenFlags, mode: u32) -> Result<File, Error> {
         // kernel_file_open() would be more appropriate for in-kernel use, as filp_open() opens in
         // the context of the current userspace thread. It's somewhat ok since we only open files
         // during module init, and this runs as root anyway.
@@ -63,7 +63,7 @@ impl File {
         }
         let path: CString = CString::new(path)
             .map_err(|err| error!("Could not convert path {path} to CString: {err}"))?;
-        let c_file = filp_open(path.as_c_str(), flags.into(), 0)
+        let c_file = filp_open(path.as_c_str(), flags.into(), mode)
             .map_err(|err| error!("Could not open file at {path:?}: {err}"))?;
         Ok(File {
             c_file,
-- 
GitLab