Skip to content

Day22 Notes - Active Update Models (Polling)

Goal

Move the sensor update path from read-triggered on-demand access to a background polling model.

The Day21 driver updated sensor data when userspace read temp1_input. In Day22, a delayed workqueue periodically updates the sensor cache, and the hwmon read path returns cached data only.

Why Polling Mode

In Day21:

  • userspace read triggers sensor update
  • I2C access happens in read path
  • read latency depends on device transaction time

In Day22:

  • background worker updates sensor periodically
  • read path becomes cache-only
  • userspace read latency is more stable
  • multiple readers do not repeatedly trigger I2C transactions

Three Update Models

1. On-demand update

Flow:

userspace read
    -> hwmon read callback
        -> update_if_needed()
            -> trigger sensor update if cache is stale
        -> return cached value

Characteristics:

  • simple design
  • fresh data on read
  • read latency may include I2C transaction time

2. Polling update

Flow:

delayed_work
    -> trigger sensor update
    -> read sensor registers
    -> refresh cache

userspace read
    -> hwmon read callback
        -> return cached value only

Characteristics:

  • stable read latency
  • no I2C transaction in read path
  • periodic bus activity even if nobody reads the value
  • data freshness depends on polling interval

3. Interrupt-driven update

Not implemented in Day22.

Typical flow:

sensor data-ready IRQ
    -> IRQ handler
        -> schedule workqueue
            -> perform I2C update
            -> refresh cache

Characteristics:

  • event-driven
  • better efficiency than polling
  • more complex design
  • usually requires firmware and hardware support

Day22 Driver Changes

Added runtime state

New fields in driver private data:

  • struct delayed_work poll_work
  • bool polling_enable
  • unsigned int polling_interval_ms

Existing cache fields remain:

  • bool cache_valid
  • long temp_mc_cached
  • unsigned long last_update
  • unsigned int cache_interval_ms

Cache Behavior

Polling enabled

When polling is enabled:

  • background delayed work updates sensor data periodically
  • temp1_input returns cached value only
  • if cache is not ready yet, read returns -EAGAIN

Polling disabled

When polling is disabled:

  • driver falls back to Day21 style on-demand update
  • read path calls myi2c_sensor_update_if_needed()

Why -EAGAIN Appears

If polling mode is enabled and the first valid sample has not been collected yet, temp1_input returns:

-EAGAIN

Userspace sees:

Resource temporarily unavailable

This is expected behavior when cache is not valid yet.

Common reasons:

  • polling worker has not run yet
  • sensor update failed
  • cache was not marked valid after update

Delayed Work in This Driver

The polling worker uses delayed_work.

Important notes:

  • it is not real-time
  • scheduling may have jitter
  • it is suitable for periodic best-effort updates
  • it is not ideal for strict timing requirements

Sysfs Controls Added in Day22

polling_enable

  • 1: enable background polling
  • 0: disable background polling

polling_interval_ms

  • polling interval in milliseconds
  • controls how often delayed work refreshes the cache

cache_interval_ms

  • used in on-demand mode
  • controls how long a cached reading remains valid before forcing update

update_once

  • manual trigger for sensor update
  • useful as a debug or fallback path

Direct Access vs Cache-Based Access

This driver now intentionally has different data paths.

temp1_input

  • standard hwmon interface
  • cache-based
  • follows polling/on-demand policy

temp_raw

  • debug interface
  • direct device access
  • bypasses cache

This separation is useful because:

  • hwmon path stays clean and predictable
  • debug path still allows direct verification of device behavior

Trade-off Summary

Model Update Trigger Read Path Pros Cons
On-demand userspace read may access I2C simple, fresh data variable latency
Polling delayed work cache-only stable read latency periodic bus activity
Interrupt IRQ + workqueue cache-only efficient, responsive more complex

Key Day22 Learning Points

  • Separate update path from read path
  • Use delayed workqueue for periodic device refresh
  • Keep hwmon read callback simple
  • Use cache validity to avoid returning invalid data
  • Understand polling as a best-effort asynchronous model
  • Prepare architecture for future interrupt-driven version