[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAhV-H4yZYkZBvn0dwCWbdhVjP9wBZ+2yPUcRo8p3m6J_89otQ@mail.gmail.com>
Date: Mon, 18 Jul 2022 16:39:19 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Jianmin Lv <lvjianmin@...ngson.cn>
Cc: Marc Zyngier <maz@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, loongarch@...ts.linux.dev,
Hanjun Guo <guohanjun@...wei.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Huacai Chen <chenhuacai@...ngson.cn>
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@...ngson.cn> wrote:
>
>
>
> On 2022/7/18 下午2:39, Marc Zyngier wrote:
> > On Mon, 18 Jul 2022 02:07:21 +0100,
> > Jianmin Lv <lvjianmin@...ngson.cn> wrote:
> >>
> >>
> >>
> >> On 2022/7/17 下午10:49, Marc Zyngier wrote:
> >>> On Sun, 17 Jul 2022 12:29:05 +0100,
> >>> Jianmin Lv <lvjianmin@...ngson.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
>
>
Powered by blists - more mailing lists