Hi Simon, On Mon, Sep 2, 2024 at 11:14 AM Patrick Rudolph <[email protected]> wrote: > > On Mon, Jul 29, 2024 at 5:28 PM Simon Glass <[email protected]> wrote: > > > > Hi Patrick, > > > > On Sat, 27 Jul 2024 at 01:20, Patrick Rudolph > > <[email protected]> wrote: > > > > > > Write MADT in common code and let the SoC fill out the body by > > > calling acpi_fill_madt() which must be implemented at SoC level. > > > > > > Signed-off-by: Patrick Rudolph <[email protected]> > > > Cc: Simon Glass <[email protected]> > > > Cc: Bin Meng <[email protected]> > > > --- > > > arch/sandbox/lib/Makefile | 9 +++--- > > > arch/sandbox/lib/acpi_table.c | 7 +++++ > > > arch/x86/cpu/intel_common/acpi.c | 20 +++++++++----- > > > arch/x86/cpu/tangier/acpi.c | 6 +++- > > > arch/x86/include/asm/acpi_table.h | 3 +- > > > arch/x86/lib/acpi_table.c | 46 ++++++------------------------- > > > include/acpi/acpi_table.h | 11 ++++++++ > > > lib/acpi/acpi_table.c | 31 +++++++++++++++++++++ > > > 8 files changed, 81 insertions(+), 52 deletions(-) > > > create mode 100644 arch/sandbox/lib/acpi_table.c > > > > Same comment as previous patch. > While it might be possible to write out GICC and LAPIC or X2APIC using > a CPU driver, > how would the other sub-tables integrate into the acpi_ops? > > On x86 you have ioapic and irq_overrides and on arm GICR and ITS sub-tables. > Would I need to add "Interrupt controller" drivers for each platform, > fill it with platform specific data > and then fill out the MADT table using acpi_ops? > > While that seems nice to have, it would be quite a lot of work, since > none of the interface > or drivers exists at the moment. > It even looks like not all platforms even use a CPU driver and even > less use an interrupt controller > driver... > I've implemented this in the latest patch series v3. See commit "drivers/arm: Implement acpi_fill_madt" that implements the driver model fill_madt for arm and allows to use it on QEMU SBSA. Other platforms are still using the "old" approach until they have been ported to the driver model.
> > > > Regards, > > Simon
