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?
Thomas has already pointed me to IRQ sim, any further help is highly
appreciated.
[1][https://patchwork.linuxtv.org/project/linux-media/patch/[email protected]/#155281]
Greetings,
Sebastian
Hi Sebastian,
On Fri, 08 Mar 2024 14:37:55 +0000,
Sebastian Fricke <[email protected]> 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.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Hey Marc,
On 09.03.2024 10:03, Marc Zyngier wrote:
>Hi Sebastian,
>
>On Fri, 08 Mar 2024 14:37:55 +0000,
>Sebastian Fricke <[email protected]> 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.