By the former article, " Hass Hi3559AV100 platform Wiegand receiving program " begs the question, this should be written in that article, but as more content and are relatively independent of one so dedicated to open an article in detail.
Before the discovery while running a program on the receiving Wiegand Hass platform, it will have lost interruption occurs, when the analysis is due Hass chip to run a lot of MPP modules that affect the external GPIO Wiegand receives the procedures used in interrupted .
Further analysis confirmed the judgment at the time, according to the results of running cat / proc / interrupts command findings obtained (see below), the vast majority are interrupted on CPU0, Wiegand also used interrupt assigned to the CPU0, which will produce the above problem.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
CPU0 CPU1 CPU2 CPU3
1: 0 0 0 0 GIC-0 29 Level arch_timer
2: 9156822 9156735 9156532 9156650 GIC-0 30 Level arch_timer
3: 0 0 0 0 GIC-0 243 Level ipcm
9: 157 0 0 0 GIC-0 38 Level uart-pl011
14: 0 0 0 0 GIC-0 63 Level pl022
15: 0 0 0 0 GIC-0 64 Level pl022
16: 0 0 0 0 GIC-0 65 Level pl022
17: 0 0 0 0 GIC-0 66 Level pl022
18: 0 0 0 0 GIC-0 67 Level pl022
19: 0 0 0 0 GIC-0 192 Level 12140000.gpio_chip
20: 0 0 0 0 GIC-0 193 Level 12141000.gpio_chip
21: 0 0 0 0 GIC-0 194 Level 12142000.gpio_chip
22: 0 0 0 0 GIC-0 195 Level 12143000.gpio_chip
23: 0 0 0 0 GIC-0 196 Level 12144000.gpio_chip
24: 0 0 0 0 GIC-0 197 Level 12145000.gpio_chip
25: 0 0 0 0 GIC-0 198 Level 12146000.gpio_chip
26: 0 0 0 0 GIC-0 199 Level 12147000.gpio_chip
27: 0 0 0 0 GIC-0 200 Level 12148000.gpio_chip
28: 0 0 0 0 GIC-0 201 Level 12149000.gpio_chip
29: 0 0 0 0 GIC-0 202 Level 1214a000.gpio_chip
30: 0 0 0 0 GIC-0 203 Level 1214b000.gpio_chip
31: 2 0 0 0 GIC-0 204 Level 1214c000.gpio_chip
32: 0 0 0 0 GIC-0 205 Level 1214d000.gpio_chip
33: 0 0 0 0 GIC-0 206 Level 1214e000.gpio_chip
34: 0 0 0 0 GIC-0 207 Level 1214f000.gpio_chip
35: 0 0 0 0 GIC-0 208 Level 12150000.gpio_chip
36: 0 0 0 0 GIC-0 209 Level 12151000.gpio_chip
37: 0 0 0 0 GIC-0 210 Level 12152000.gpio_chip
38: 0 0 0 0 GIC-0 215 Level 180d3000.shub_gpio
39: 0 0 0 0 GIC-0 43 Level 180b0000.rtc
40: 5588734 0 0 0 GIC-0 68 Level 101c0000.ethernet
42: 212 0 0 0 GIC-0 116 Level xhci-hcd:usb1
43: 0 0 0 0 GIC-0 117 Level xhci-hcd:usb3
44: 2314 0 0 0 GIC-0 58 Level mmc0
45: 0 0 0 0 GIC-0 106 Level mmc1
46: 0 0 0 0 GIC-0 107 Level mmc2
53: 0 0 0 0 GIC-0 113 Level hiedmacv310
55: 0 0 0 0 GIC-0 92 Level VI_CAP0
56: 0 0 0 0 GIC-0 93 Level VI_PROC0
57: 0 0 0 0 GIC-0 94 Level VI_PROC1
58: 0 0 0 0 GIC-0 118 Level SLVS_EC0
59: 0 0 0 0 GIC-0 120 Level MIPI0
60: 796266 0 0 0 GIC-0 77 Level VPSS0
61: 43022 0 0 0 GIC-0 78 Level VPSS1
62: 690722 0 0 0 GIC-0 75 Level VGS0
63: 222459 0 0 0 GIC-0 76 Level VGS1
64: 0 0 0 0 GIC-0 79 Level GDC0
65: 0 0 0 0 GIC-0 80 Level GDC1
66: 0 0 0 0 GIC-0 83 Level DIS
67: 0 0 0 0 GIC-0 184 Level AVS
68: 0 0 0 0 GIC-0 99 Level VO Int
69: 0 0 0 0 GIC-0 100 Level HIFB Int
70: 0 0 0 0 GIC-0 95 Level MIPI_TX
72: 0 0 0 0 GIC-0 71 Level VEDU_0
73: 0 0 0 0 GIC-0 72 Level VEDU_1
74: 0 0 0 0 GIC-0 73 Level VEDU_2
75: 652 0 0 0 GIC-0 81 Level JPGE_0
76: 0 0 0 0 GIC-0 123 Level vdh_bd
77: 912964 0 0 0 GIC-0 124 Level vdh_pd
78: 861008 0 0 0 GIC-0 126 Level vdh_scd
79: 0 0 0 0 GIC-0 84 Level JPEGD_0
80: 484599 0 0 0 GIC-0 90 Level nnie0
81: 484821 0 0 0 GIC-0 91 Level nnie1
82: 0 0 0 0 GIC-0 240 Level DPU RECT
83: 0 0 0 0 GIC-0 241 Level DPU MATCH
84: 326 0 0 0 GIC-0 88 Level IVE
86: 0 0 0 0 GIC-0 101 Level AIO Interrupt
87: 1 0 0 0 GIC-0 134 Level 11c00000.gpu
88: 3 0 0 0 GIC-0 85 Level tde_osr_isr
89: 1 0 0 0 GIC-0 135 Level 11c00000.gpu
90: 1 0 0 0 GIC-0 133 Level 11c00000.gpu
97: 0 0 0 0 pl061 2 Edge rst
193: 1 0 0 0 pl061 2 Edge wiegand_data1
195: 1 0 0 0 pl061 4 Edge wiegand_data0
IPI0: 1297810 2253123 4008151 9711865 Rescheduling interrupts
IPI1: 21 10 25 10 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 Timer broadcast interrupts
IPI4: 0 0 0 0 IRQ work interrupts
IPI5: 0 0 0 0 CPU wake-up interrupts
Err: 0
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
How can I solve this problem? Find a solution on the Internet.
1. The use of the echo command cpu mask writing / proc / irq / interrupt ID / smp_affinity document, you can achieve a modified affinity for interrupt to the CPU.
According to this method of operating echo. 4> / proc / IRQ / 193 / the smp_affinity , the results suggest the following errors:
echo: write error: Input/output error
According to another solution to this problem, the answer is disappointing, this is a hardware or operating system decisions, no solution!
Method 1 fails.
2. not resolved from the application layer, focusing on the core layer to find a solution. Such a kernel function: irq_set_affinity (clock_event_device-> irq, cpumask); cpu IRQ will be associated with one or several indicating which service the cpu irq.
According to this method of code modification module, add the following statement:
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
struct cpumask cpumask;
cpumask.bits[0] = (unsigned long)0x02;
irq_set_affinity_hint(wiegand_in_devp->d0_irq, &cpumask);
irq_set_affinity_hint(wiegand_in_devp->d1_irq, &cpumask);
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
irq_set_affinity_hint function is in kernel / irq / manage.c, it __irq_set_affinity function calls, which in turn calls a function irq_set_affinity.
This method seems to fundamentally solve the problem, but actually compile and run the module was observed after Wigan two GPIO interrupt, or assigned to the CPU0, CAT / proc / IRQ / 193 / smp_affinity results still f, no change . Why is that? Continue to join in the kernel code print debug problems found in here (see below in bold red):
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
int irq_set_affinity_locked(struct irq_data *data, const struct cpumask *mask,
bool force)
{
struct irq_chip *chip = irq_data_get_irq_chip(data);
struct irq_desc *desc = irq_data_to_desc(data);
int ret = 0;
printk("111\n");
if (!chip || !chip->irq_set_affinity)
return -EINVAL;
printk("222\n");
if (irq_can_move_pcntxt(data)) {
ret = irq_do_set_affinity(data, mask, force);
} else {
irqd_set_move_pending(data);
irq_copy_pending(desc, mask);
}
if (desc->affinity_notify) {
kref_get(&desc->affinity_notify->kref);
schedule_work(&desc->affinity_notify->work);
}
irqd_set(data, IRQD_AFFINITY_SET);
Return the right;
}
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Did not actually run down, this should be due to the chip-> irq_set_affinity empty lead, but the specific why is empty, should be set up where further research is needed on how to set up ......
