Day 24 - Polling / IRQ Hybrid Model

Overview

This chapter introduces a hybrid data update model that combines:

• Interrupt-driven updates (IRQ)
• Periodic polling (workqueue)
• On-demand updates (read path)

The goal is to balance:

• Low latency (IRQ)
• Reliability (polling fallback)
• Simplicity (on-demand)

---

Update Modes

Mode	Description
ON_DEMAND	Update only when user reads
POLLING	Periodic updates via workqueue
IRQ	Updates triggered by interrupt
HYBRID	IRQ + polling fallback

---

Hybrid Design

Concept:

IRQ  -> Primary (low latency)
POLL -> Fallback (reliability)

Behavior:

• If IRQ is enabled → prefer IRQ
• If IRQ is missing or stale → polling updates data
• Ensures eventual consistency

---

Architecture

1. Update Entry

myi2c_sensor_update_by_trigger_locked(...)

Responsibilities:

• Determine update source (IRQ / POLL / DEMAND)
• Check whether update is needed
• Perform hardware read

---

2. Polling Workqueue

poll_work_callback()
{
    mutex_lock(...)
    update_by_trigger(...)
    snapshot state
    mutex_unlock(...)

    if (enable)
        schedule_next(...)
}

Key rule:

• Scheduling must happen outside the lock

---

3. Control Plane (sysfs)

Attribute	Purpose
polling_enable	Enable/disable polling
polling_interval_ms	Polling interval
irq_enable	Enable/disable IRQ
debug_status	Runtime status

---

4. Observability

Example output:

mode=hybrid
cache_valid=1
last_source=poll
irq_enable=1
polling_enable=1
irq_count=10
poll_count=25
last_update_ms=120
last_irq_ms=500
last_poll_ms=120

Provides visibility into:

• Current mode
• Data source
• Timing behavior
• Event counters

---

Concurrency Design

Principles

• Protect shared state with mutex
• Avoid scheduling under lock
• Use snapshot pattern

---

Pattern

mutex_lock()
update state
snapshot
mutex_unlock()

if (needed)
    schedule_work()

---

Race Condition Philosophy

Example:

callback unlock
→ user disables polling
→ callback still schedules once

Result:

• One extra work execution
• No crash
• System stabilizes

Conclusion:

• Acceptable race
• Favor stability over strict locking

---

Key Takeaways

• Hybrid model improves robustness
• IRQ alone is not always reliable
• Workqueue design must avoid deadlocks
• Observability is critical for debugging