Messages in this thread | | | Date | Wed, 13 Mar 2024 17:24:27 +0100 | From | Sebastian Fricke <> | Subject | Re: RFC: fake IRQchip |
| |
Hey Marc,
On 09.03.2024 10:03, Marc Zyngier wrote: >Hi Sebastian, > >On Fri, 08 Mar 2024 14:37:55 +0000, >Sebastian Fricke <sebastian.fricke@collabora.com> wrote: >> >> Hey, >> >> I am one of the maintainers of the media subsystem and we are currently >> reviewing a patch [1], where the author has developed a polling >> mechanism for a driver, while the hardware (Wave5 Codec) actually always >> expects an interrupt line to be present and the only reason why this >> isn't uphold is because the SoC has a defect, causing the interrupt line >> to be disabled. >> As I am a bit reluctant to litter a driver with workarounds for defective >> hardware, I suggested to the author, that he could implement fake >> IRQchip, which does polling in the background. This could first be >> implemented in the driver directory and then later possibly upstreamed >> to /drivers/irqchip. >> So, far I've got a few approving comments for that idea, but I would >> really like to know what the irqchip folks think about this. >> >> Now my question is basically, what do you think about such a solution? Would >> you accept such a fake irqchip driver, that can be used by >> hardware without an interrupt line to fake one? Do you think there is a >> better solution or do you think that my suggestion has hidden traps? > >The problem with this approach is that it cannot be a generic irqchip, >because it needs to know about the endpoint device to find out when >the interrupt has been cleared. This is specially true for level >signalling. If the device was only doing edge signalling, I could see >a vague path forward, but that's not the case here (as evidenced by >the DT bindings). > >My view on this is that given that the workaround has to know quite a >few things about the generating device, it is better kept close to the >driver code.
Alright thanks for your feedback. So in that case implementing polling is definitely the better option as implementing a unique fake IRQchip per driver seems not very efficient.
> >Thanks, > > M.
Greetings, Sebastian
> >-- >Without deviation from the norm, progress is not possible.
| |