On Thu, Aug 27, 2020 at 04:42:04PM +0100, Marc Zyngier wrote: > Cristian, > > On 2020-08-27 16:24, Cristian Ciocaltea wrote: > > Hi Marc, > > > > On Thu, Aug 27, 2020 at 11:35:06AM +0100, Marc Zyngier wrote: > > > On 2020-08-27 11:06, Cristian Ciocaltea wrote: > > > > On Wed, Aug 26, 2020 at 04:48:38PM -0600, Rob Herring wrote: > > > > > On Wed, Aug 26, 2020 at 3:42 PM Cristian Ciocaltea > > > > > <cristian.ciocaltea@xxxxxxxxx> wrote: > > > > > > [...] > > > > > > > > Ultimately the GIC trigger type has to be > > > > > something. Is it fixed or passed thru? If the latter, just use 0 > > > > > (IRQ_TYPE_NONE) if the GIC trigger mode is not fixed. Having some sort > > > > > of translation of the trigger is pretty common. > > > > > > > > Yes, as explained above, the SIRQ controller performs indeed the > > > > translation of the incoming signal. So if I understand correctly, your > > > > suggestion would be to use the following inside the sirq node: > > > > > > > > interrupts = <GIC_SPI 13 IRQ_TYPE_NONE>, /* SIRQ0 */ > > > > [...] > > > > > > Please don't. If you are describing a GIC interrupt, use a > > > trigger that actually exists. Given that you have a 1:1 > > > mapping between input and output, just encode the output > > > trigger that matches the input. > > > > Understood, the only remark here is that internally, the driver will > > not use this information and instead will continue to rely on the input > > to properly set the trigger type for the output. > > It's fine. The binding has to be consistent on its own, but > doesn't dictate the way the driver does thing. > > > The question is if the driver should also emit a warning (or error?) > > when the trigger type supplied via DT doesn't match the expected value. > > Rob will tell you that the kernel isn't a validation tool for broken > DTs. Shout if you want, but you are allowed to simply ignore the > output trigger for example > > > If yes, we should also clarify what the user is supposed to provide in > > the controller node: the trigger type before the conversion (the input) > > or the one after the conversion (the output). > > The output of a SIRQ should be compatible with the GIC input it is > attached to. You can have: > > device (LEVEL_LOW) -> SIRQ (LEVEL_HIGH) -> GIC > > but you can't have: > > device (LEVEL_LOW) -> SIRQ (EDGE_RISING) -> GIC > > because that's not an acceptable transformation for the SIRQ, > nor can you have: > > device (EDGE_FALLING) -> SIRQ (EDGE_FALLING) -> GIC > > because EDGE_FALLING isn't a valid input for the GIC. > > In both of the invalid cases, you would be free to apply > which ever transformation actually makes sense, and shout > at the user if you want to help them debugging their turf. > The later part is definitely optional. > > Hope this helps, This certainly helps a lot, now I have a clear understanding of what is to be done next. > M. > -- > Jazz is not dead. It just smells funny... Many thanks for the detailed explanations, Cristi
