Hi Simon, On Sat, Jul 18, 2015 at 10:37 PM, Simon Glass <[email protected]> wrote: > Hi Bin, > > On 15 July 2015 at 02:23, Bin Meng <[email protected]> wrote: >> Currently during writing MP table I/O interrupt assignment entry, we >> assume the PIRQ is directly mapped to I/O APIC INTPIN#16-23, which >> however is not always the case on some platforms. >> >> Signed-off-by: Bin Meng <[email protected]> >> --- >> >> arch/x86/include/asm/mpspec.h | 17 +++++++++++++++++ >> arch/x86/lib/mpspec.c | 23 ++++++++++++++++------- >> 2 files changed, 33 insertions(+), 7 deletions(-) >> >> diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h >> index efa9231..ad8eba9 100644 >> --- a/arch/x86/include/asm/mpspec.h >> +++ b/arch/x86/include/asm/mpspec.h >> @@ -432,6 +432,23 @@ void mp_write_compat_address_space(struct >> mp_config_table *mc, int busid, >> u32 mptable_finalize(struct mp_config_table *mc); >> >> /** >> + * mp_determine_pci_dstirq() - Determine PCI device's int pin on the I/O >> APIC >> + * >> + * This determines a PCI device's interrupt pin number on the I/O APIC. >> + * >> + * This can be implemented by platform codes to handle specifal cases, which >> + * do not conform to the normal chipset/board design where PIRQ[A-H] are >> mapped >> + * directly to I/O APIC INTPIN#16-23. >> + * >> + * @bus: bus number of the pci device >> + * @dev: device number of the pci device >> + * @func: function number of the pci device >> + * @pirq: PIRQ number the PCI device's interrupt pin is routed to >> + * @return: interrupt pin number on the I/O APIC >> + */ >> +int mp_determine_pci_dstirq(int bus, int dev, int func, int pirq); >> + >> +/** >> * write_mp_table() - Write MP table >> * >> * This writes MP table at a given address. >> diff --git a/arch/x86/lib/mpspec.c b/arch/x86/lib/mpspec.c >> index f16fbcb..f90567c 100644 >> --- a/arch/x86/lib/mpspec.c >> +++ b/arch/x86/lib/mpspec.c >> @@ -269,6 +269,12 @@ static bool check_dup_entry(struct mpc_config_intsrc >> *intsrc_base, >> return (i == entry_num) ? false : true; >> } >> >> +__weak int mp_determine_pci_dstirq(int bus, int dev, int func, int pirq) > > I'd like to avoid using weak functions. Can we use device tree or > driver model instead? >
As you can see in this patch http://patchwork.ozlabs.org/patch/495524/, that the return value of this function (dstirq) relies on the runtime value, so we cannot describe it in the device tree. As for driver model, I am not sure if if it suits. I will need think about it. If we do driver model, we might be able to consolidate PIRQ and MP table codes. Can we leave this to a possible future work? > In principle we should be able to build all of the code in and boot an > image on multiple boards. These sorts of things make it harder to > understand and follow the code IMO. > Yep, ideally although I don't know how practical for now :-) [snip] Regards, Bin _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
