On Thu, Aug 12, 2021 at 1:05 PM Huacai Chen <chenhuacai@xxxxxxxxx> wrote:
> On Tue, Jul 6, 2021 at 6:16 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > > +
> > > +static inline void check_bugs(void)
> > > +{
> > > + unsigned int cpu = smp_processor_id();
> > > +
> > > + cpu_data[cpu].udelay_val = loops_per_jiffy;
> > > +}
> >
> > This needs a comment to explain what bug you are working around.
> OK, there is "no bug" at present, just set the CPU0's udelay_val here.
Can you do this elsewhere?
I think the normal place would be somewhere around calibrate_delay(),
which has various options.
If the CPU has a well-defined hardware timer, you should not need to
know any loops_per_jiffy value but simply wait for the correct number
of cycles in delay()
> > Can you send a cleanup patch for this? I think we should get rid of the
> > isa_dma_bridge_buggy variable for architectures that do not have a VIA
> > VP2 style ISA bridge.
> We doesn't need ISA, but isa_dma_bridge_buggy is needed in drivers/pci/pci.c
Ah right, of course. We should clean that up one day so architectures
don't have to
define this, I don't think anything but x86 can actually set it to a value other
than zero.
> > > +#ifdef CONFIG_64BIT
> > > +#define TASK_SIZE32 0x80000000UL
> >
> > Why is the task size for compat tasks limited to 2GB? Shouldn't these
> > be able to use the full 32-bit address space?
> Because we use 2:2 to split user/kernel space.
Usually in compat mode, the user process can access all 4GB though, regardless
of what native 32-bit tasks can do.
Is there a limitation on loongarch that prevents you from doing this?
> > > +#ifdef CONFIG_VA_BITS_40
> > > +#define TASK_SIZE64 (0x1UL << ((cpu_vabits > 40)?40:cpu_vabits))
> > > +#endif
> > > +#ifdef CONFIG_VA_BITS_48
> > > +#define TASK_SIZE64 (0x1UL << ((cpu_vabits > 48)?48:cpu_vabits))
> > > +#endif
> >
> > Why would the CPU have fewer VA bits than the page table layout allows?
> PAGESIZE is configurable, so the range a PGD can cover is various, and
> VA40/VA48 is not exactly 40bit/48bit, but 40bit/48bit in maximum.
Do you mean the page size is not a compile-time constant in this case?
What are the combinations you can support? Is this a per-task setting
or detected at boot time?
> > > +/*
> > > + * Subprogram calling convention
> > > + */
> > > +#define _LOONGARCH_SIM_ABILP32 1
> > > +#define _LOONGARCH_SIM_ABILPX32 2
> > > +#define _LOONGARCH_SIM_ABILP64 3
> >
> > What is the difference between ILP32 and ILPX32 here?
> >
> > What is the ILP64 support for, do you support both the regular LP64 and ILP64
> > with 64-bit 'int'?
> ABILP is ABI-LP, not AB-ILP. :). LP32 is native 32bit ABI, LP64 is
> native 64bit ABI, and LPX32 something like MIPS N32/X86 X32 (not exist
> in the near future).
I would suggest you don't plan to ever add LPX32 in this case, it
has never really caught on for any of the architectures that support
it other than mips, and even there I don't think it is used much
any more.
It's certainly easier to have fewer ABI options.
Arnd
