You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our device name is derived from the address the peripheral sits at in
mmio space; this is not useful for users. Instead name it after the i2c
bus.
Milton explains why this is important for IRQ debugging:
The aspeed i2c controller has an irq per bus and this has been
exposed as an irq domain. However, each irq is requested the same
device name, leaving one to guess which irq in /proc/interrupts
corresponds to which device. While the controller irq number
is unique and happens to match, it is not obvious that there is
no offset.
The driver registers the bus with the numbered bus api, so the
global bus number is known an we can predict it before registering.
The information that this is from an ast-i2c bus is in the irq
controller name or could be found from the matching i2c bus device
in sysfs.
Excerpt of /proc/interrupts before this patch:
220: 1094 ast-i2c 0 Edge ast-i2c-bus
221: 0 ast-i2c 1 Edge ast-i2c-bus
222: 9438 ast-i2c 2 Edge ast-i2c-bus
223: 26480 ast-i2c 3 Edge ast-i2c-bus
New excerpt from /proc/interrupts:
220: 1094 ast-i2c 0 Edge i2c-0
221: 0 ast-i2c 1 Edge i2c-1
222: 9438 ast-i2c 2 Edge i2c-2
223: 26480 ast-i2c 3 Edge i2c-3
224: 0 ast-i2c 4 Edge i2c-4
New example proc/irq/ directory:
/proc/irq/222:
i2c-2 spurious
Signed-off-by: Joel Stanley <[email protected]>
0 commit comments