Hi Jakub, On 03.10.2015 19:23, Jakub Kicinski wrote: > On Wed, 30 Sep 2015 23:57:57 +0300, Vladimir Zapolskiy wrote: >> Hardcode IC irq type to IRQF_TRIGGER_FALLING for both platform and OF >> cases. According to the datasheet IC irq line is active low, reflect >> this fact in the driver. >> >> If sc16is7xx device is described in devicetree, the change fixes >> the following problem and makes the driver working correctly: >> >> root@devkit3250:~# stty -F /dev/ttySC1 115200 >> INFO: rcu_preempt self-detected stall on CPU >> 0: (2100 ticks this GP) idle=a79/140000000000002/0 softirq=1759/1759 fqs=0 >> (t=2100 jiffies g=910 c=909 q=2) >> rcu_preempt kthread starved for 2100 jiffies! g910 c909 f0x0 s3 ->state=0x1 >> Task dump for CPU 0: >> stty R running 0 698 696 0x00000002 >> ...... >> >> Signed-off-by: Vladimir Zapolskiy <vz@xxxxxxxxx> > > NAK > > I'm with Alexander on this one. Did you honestly configure the device > in a wrong way by mistake or is it a hypothetical problem? this is an actually met problem, but I do admit that it might be a misconfiguration on my side, problem in the discussed driver or an indicator of another IRQ chip platform problem, I know at least one critical issue within the current implementation of IRQ controller driver on LPC32xx. To give you more evidence I have to retest sc16is7xx driver, and unfortunately I don't have access to the hardware for one week. Meanwhile I would be glad to get answers to two questions regarding sc16is7xx / irq type: 1) how is it intended to specify proper IRQ type in the driver, if interrupt controller's #interrupt-cells property has only one cell? 2) if you stay for flexibility, why does sc16is7xx realization in platform device description case hardcode IRQF_TRIGGER_FALLING? Thanks. -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
