Hi Jakub, On 10.10.2015 16:02, Jakub Kiciński wrote: > On Sun, 04 Oct 2015 22:12:20 +0100, Vladimir Zapolskiy wrote: >> 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. the problem was on my side, the change in the driver is not needed. > OK, my thougth was that maybe we should improve the documentation > somehow. Although, I'm not sure where to put it, the binding file > is probably not right for the IRQ information. > >> 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? > > Do you mean the controller does not provide a way to specify the > triggering edge etc.? Yes. >> 2) if you stay for flexibility, why does sc16is7xx realization in >> platform device description case hardcode IRQF_TRIGGER_FALLING? > > AFAIR it's the default. I did not write that code, though. > Well, according to the code this is an only option. -- 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
