On Thu, May 3, 2018 at 11:11 AM, Rob Herring <[email protected]> wrote: > On Thu, May 3, 2018 at 9:29 AM, Alexander Graf <[email protected]> wrote: >> On 04/30/2018 08:36 PM, Rob Herring wrote: >>> >>> On Fri, Apr 27, 2018 at 4:39 PM, Alexander Graf <[email protected]> wrote: >>>> >>>> Hi Rob, >>>> >>>> On 27.04.18 18:40, Rob Herring wrote: >>>>> >>>>> On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On 27.04.18 08:24, Udit Kumar wrote: >>>>>>> >>>>>>> Hi >>>>>>> There is bit of discussion on linux-efi too , to handle DT update >>>>>>> >>>>>>> I guess some members of this forum are active there too. >>>>>>> >>>>>>> https://www.spinics.net/lists/linux-efi/msg13700.html >>>>>>> >>>>>>> To summaries >>>>>>> 1/ Ownership of DTB >>>>>>> IMO should be firmware and we should retain this >>>>>>> ownership in EBBR as well, Any objections/thoughts ? >>>>>> >>>>>> I fully agree. On top of that we need to make clear that backward and >>>>>> forward compatibility are not optional. >>>>>> >>>>>> For that I think we may need to actually give people workable solutions >>>>>> to create device trees that are compatible with multiple levels of >>>>>> kernel support. The main areas I'm aware of that keep breaking are: >>>>>> >>>>>> * fine grained interrupt controller support >>>>> >>>>> Do you have an example of that? The only thing I can think of is >>>>> people switching interrupts from the GIC to an always-on, low-power >>>>> mode custom interrupt controller. >>>> >>>> The last time I've seen that breakage was: >>>> >>>> >>>> >>>> https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/bcm270x.dtsi#L158 >>>> >>>> which indeed does switch interrupts from the GIC to an interrupt muxer >>>> behind the GIC. >>>> >>>> The problem is that once support for that lands upstream, you will have >>>> very little option but to break backwards compatibility today. >>> >>> This one is unfortunate. It could have been handled better. An >>> interrupt-map property in the aux ctrlr could have mapped the >>> interrupts to GIC without any aux driver. Then when the aux driver >>> lands, it just needs to remove the interrupt-map (on boot). >> >> >> To do that you would've needed to know that you need the change in the first >> place ;). > > Actually, I think we can still solve this. Add the interrupt-map now. > Then when the aux driver lands it has to fixup the interrupt-map.
Scrap that... > I think I actually hit the problem when testing my deferred probe > patch. I saw a 30 sec delay in the console output when the pl011 > driver probed and using the pl011 as the console (they really made a > mess of the serial console on RPi 3). > >>> Alternatively, I skimmed thru some discussions of the issue, but I'm >>> not clear why the devices behind the aux controller can't all just >>> treat their interrupts as shared. But that would be a simple change to >>> the drivers' irq handlers, so I'm probably missing something. If that >>> worked, then the DT would never need to change. Fix posted[1]. :) In fact the IRQ handlers are shared already, there's just a bug in the handler. Rob [1] https://patchwork.kernel.org/patch/10378841/ _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
