Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
> > GIC and arch timer. Basically the minimal kernel would need a timer
> > for the scheduler tick and IRQ controller to get the timer IRQ and the
> > fixed clock driver if the archtimer uses one to get its frequency and
> > the early UART console is pointless as a module (so build it in to
> > allow debugging/development).
> >
> > And then all new drivers, we should make sure are implemented as
> > tristate drivers. And we can go back and slowly work on converting
> > existing drivers to modules (community effort -- not one person or
> > entity) -- at least the ones where the author has hardware or ones
> > where the change is very likely to be correct and someone else is
> > willing to test it. We'll never be able to support some/all ARM32 (do
> > they even have a GIC/arch timer standard?), but at least for ARM64,
> > this seems like a viable goal.
>
> Cortex-A7/A15 and later have GIC and architectured timer, so it should
> work for contemporary systems.
> Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
> seen SoCs where the interrupt for the latter was not wired :-(.

There are a number of well-known examples even with 64-bit chips or
Cortex-A7/A15 based SoCs that can't use the architected timer,
irqchip or iommu.

Apple M1, Broadcom BCM283x, Samsung Exynos5 and
some Hisilicon server parts come to mind, I'm sure there
are more.

> What are the plans for other architectures?
> I've seen similar patches being applied for e.g. MIPS.

There is some work in the more actively maintained MIPS
platforms to make those behave more like Arm/powerpc/riscv/m68k
platforms, using a single image and moving drivers into modules.
Most MIPS platforms seem unlikely to get updated to this,
and will continue to require a SoC specific kernel binary forever,
similar to the renesas superh platforms. Most of the less
common architectures (arc, csky, hexagon, nios2, xtensa,
microblaze, nds32, openrisc, sparc/leon) are way behind that
though, and generally don't work at all without out-of-tree
code.

      Arnd



[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux