--- Comment #14 from Zoltan Boszormenyi ( ---
(In reply to Zhang Rui from comment #13)
> Sorry, I'm a little confused.
> (In reply to Zoltan Boszormenyi from comment #10)
> > (In reply to Zhang Rui from comment #8)
> > > Hi, Zoltan, any updates?
> > 
> > Regarding the tablet in question, it turned out that the touchscreen is
> > actually I2C and is correctly handled by the i2c-hid-acpi driver. We didn't
> > have this driver enabled before.
> Does the problem go away after you enabling this driver?
> If yes, is there any other problem that blocks us from closing this bug
> report?
> If no, do you mean it is still the IRQ problem still exists after enabling
> the i2c-hid-acpi driver? And can you try custom DSDT as I suggested?

There were two orthogonal issues here.

1. the touchscreen didn't work, believed to be UART based but actually I2C and
fixed by i2c-hid-acpi

2. the ttyS0 UART IRQ is wrong if the IRQ subsection for the specific device
contains an empty IRQ () or IRQNoFlags () subsection.

This ticket is about the latter.

Possibly the Linux kernel's default IRQ parameters are wrong and the IOAPIC is
programmed wrongly.

My patch that I attached here tries to collect the default legacy IRQ
parameters from the PCI Interrupt Link device, but the kernel fails to use it.

Without irq_set_irq_type() in the patch, the IRQ stays edge triggered with
extra messages in dmesg telling the IRQ is overridden to edge triggered.

With  irq_set_irq_type() in the patch, the IRQ becomes fasteoi instead of level
triggered, resulting in the IRQ being disabled very quickly.

Possibly a small change may make the patch work but I don't know enough to make
it work. It is also possible that by the time this code is reached, it's too
late for IRQ setup in the APIC/IOAPIC.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

acpi-bugzilla mailing list

Reply via email to