lkml.org 
[lkml]   [2024]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.

\
 
 \ /
  Last update: 2024-03-13 17:24    [W:0.055 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site