On Thu, Jul 2, 2015 at 5:41 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 30 June 2015 at 21:10, Peter Crosthwaite > <peter.crosthwa...@xilinx.com> wrote: >> On Tue, Jun 30, 2015 at 12:42 PM, Peter Maydell >> <peter.mayd...@linaro.org> wrote: >>> On 30 June 2015 at 20:01, Peter Crosthwaite >>> <peter.crosthwa...@xilinx.com> wrote: >>>> So I actually had my own patches for this one that went in a different >>>> direction. The reason is, there are also other devs out there which >>>> need post-firmware state setup. The one I an thinking of mainly is the >>>> Zynq SLCR setup for non-firmware boots, I.E. the Linux kernel expects >>>> firmware to setup devices to some sort of initialized state (mainly >>>> turning clocks on). I think this GIC setup falls in the same category. >>>> The third use case is the GIC_CPU_IF stuff currently managed by >>>> machine code in boot.c that could be outsourced to GIC (in either a >>>> similar way to what is done here, or more fully outsourced using my >>>> new API). >>> >>> I'm a bit torn here -- I don't want to make it *too* easy for >>> people to add linux-booting specific code to random devices, >>> as this will lead to the bootloader code having its tentacles >>> everywhere within the tree... > > So I thought about this a bit, and I guess that having a general > interface is probably better than specifically setting a GIC > property. It does need to be called once at arm_kernel_load_notify > time, not as a reset hook. I also think it should pass in the > arm_boot_info* as a parameter. This would let the GIC do the > right thing based on whether we're booting S or NS. > > Are you planning to respin this patchset, or should I just pull > the relevant bits into my series? >
Just pull relevants I think. Should be just patches 1 and 2, the boot.c one needs rewrite and the gic one is a write-off as yours is much more functionally correct. Regards, Peter > thanks > -- PMM >
