Messages in this thread | | | From | Huacai Chen <> | Date | Mon, 18 Jul 2022 16:39:19 +0800 | Subject | Re: [PATCH V15 00/15] irqchip: Add LoongArch-related irqchip drivers |
| |
Hi, Jianmin and Marc,
On Mon, Jul 18, 2022 at 4:29 PM Jianmin Lv <lvjianmin@loongson.cn> wrote: > > > > On 2022/7/18 下午2:39, Marc Zyngier wrote: > > On Mon, 18 Jul 2022 02:07:21 +0100, > > Jianmin Lv <lvjianmin@loongson.cn> wrote: > >> > >> > >> > >> On 2022/7/17 下午10:49, Marc Zyngier wrote: > >>> On Sun, 17 Jul 2022 12:29:05 +0100, > >>> Jianmin Lv <lvjianmin@loongson.cn> wrote: > >>>> > >>>> > >>>> > >>>> On 2022/7/17 下午6:02, Marc Zyngier wrote: > >>>>> But the other issue is that you seem to call this function from two > >>>>> different locations. This cannot be right, as there should be only one > >>>>> probe order, and not multiple. > >>>>> > >>>> > >>>> As we described two IRQ models(Legacy and Extended) in this cover > >>>> letter, the parent domain of MSI domain can be htvec domain(Legacy) or > >>>> eiointc domain(Extended). In MADT, only one APIC(HTPIC for htvec or > >>>> EIOPIC for eiointc) is allowed to pass into kernel, and then in the > >>>> irqchip driver, only one kind APIC of them can be parsed from MADT, so > >>>> we have to support two probe order for them. > >>> > >>> Do you really have the two variants in the wild? Or is this just > >>> because this is a possibility? > >>> > >> > >> Currently, there are not CPUs(used for PC and server) based on > >> LoongArch shipped with only HTPIC, but with both HTPIC and EIOPIC, we > >> just want to provide two choices for designers(but obviously, EIOPIC > >> may be enough currently). Do you think we don't have to do like this, > >> yes? If so, maybe we don't have to support ACPI-way entry for htvec > >> currently, and do the work in future if required. > > > > If the existing HW is only following the 'Extended' model, then I'd > > suggest you only support this for now. It has two effects: > > > > - it simplifies the current code, making it more maintainable and > > easier to reason about > > > > - it sends the message to integrators that 'Extended' is the correct > > model, and that it is what they should support > > > > Now, we don't have much time left to get this series into -next (I > > will be closing the tree to new features this week, and only queue > > fixes). > > > > So whatever you need to do, please do it quickly so that we can have > > at least some of this in 5.20. > > > > Thanks, > > > > M. > > > > Ok, Marc, thanks for your suggestion, got it, I'll remove 'Legacy' mode > support and send next version as soon as possible. I think keeping the "Legacy" mode is faster than removing it for now to keep up with the merge window, since it is already here and doesn't need to modify.
Huacai > >
| |