Am Dienstag, den 22.01.2019, 10:56 +0000 schrieb Aisheng Dong: > > > > From: Marc Zyngier [mailto:marc.zyngier@xxxxxxx] > > Sent: Friday, January 18, 2019 6:12 PM > > [...] > > > > > > > > From: Marc Zyngier [mailto:marc.zyngier@xxxxxxx] > > > > Sent: Friday, January 18, 2019 5:39 PM On 18/01/2019 08:48, Lucas > > > > Stach wrote: > > > > > Am Freitag, den 18.01.2019, 07:53 +0000 schrieb Aisheng Dong: > > > > > > Not all 64 interrupts may be used in one group. e.g. most irqsteer > > > > > > in imx8qxp and imx8qm subsystems supports only 32 interrupts. > > > > > > > > > > > > As the IP integration parameters are Channel number and interrupts > > > > > > number, let's use fsl,irqs-per-chan to represents how many > > > > > > interrupts supported by this irqsteer channel. > > > > > > > > > > Sorry, but total NACK. I've got to great lengths with dumping the > > > > > actually implemented register layout on i.MX8M and AFAICS the IRQs > > > > > are always managed in groups of 64 IRQs, even if less than that are > > > > > connected as input IRQs. This is what the actually present register > > > > > set on i.MX8M tells us. > > > > > > > > Also, I'd really like the DT bindings not to change at every release. > > > > So whatever change (if any) has to be done for this driver to support > > > > existing HW, please make sure that the DT bindings are kept as stable as > > > > possible. > > > > > > > > > > Sorry I should clarify it a bit. > > > There's still no users in Devicetree. > > > So I guess we can update it, right? Or not? > > > > What do you mean by no users? This driver is in 5.0, and I assume people are > > using it one way or another. Not having a platform in the kernel tree is pretty > > much irrelevant, as the kernel tree is not a canonical repository of existing > > platforms. > > > > I understand the concern. > Theoretically yes, but it's very unlikely that there's already an out of tree users > wants to use it for a long term as we're still at the very initial stage. > > And the most important reason is that current using actually is wrong. > We can also choose to mark it as 'depreciated' and keep the backward compatibility in driver, > but I'm not sure whether it's worthy to do it as we may add a lot ugly code in driver > benefits no users. > > Ideas? I'm all for doing a breaking DT change now. The binding is significantly different from the downstream one anyways and I'm not aware of any upstream users that wouldn't be able to cope with a change at this point. I want to reach a conclusion on the discussion about how the HW actually works and is configured in reply to Patch 4/4 first. Regards, Lucas
