On Wed, Jan 24, 2024, at 14:16, Linus Walleij wrote:
> On Wed, Jan 24, 2024 at 1:55 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
>> > So I am seeing if these can be excluded from the "most omap2plus
>> > systems" list.
>>
>> Unfortunately excluding Nokia n8x0 would turn the omap2plus
>> defconfig into an omap3plus_defconfig effectively.
>
> I did like this:
>
> @@ -135,7 +135,7 @@ config ARCH_OMAP2PLUS_TYPICAL
> bool "Typical OMAP configuration"
> default y
> select AEABI
> - select HIGHMEM
> + select HIGHMEM if !SOC_OMAP2420
>
> Effectively disabling HIGHMEM when using omap2plus_defconfig.
>
> If we want all systems supported, we just apply this at the expense
> of highmem for OMAP 2430, OMAP3 and OMAP4 and the
As far as I can tell, none of the above actually have more than
1GB of RAM, as OMAP4/AM4 maxes out at a single 8Gbit LPDDR2
RAM. For those machines, using CONFIG_VMSPLIT_3G_OPT is likely
going to be much better than CONFIG_HIGHMEM anyway.
Unfortunately, this does not work for OMAP5/AM5/DRA7, which
can have 2GB or possibly 4GB (as used in the Pyra) of DDR3,
so we'd still lose.
> We can then either
>
> - Disable SOC_OMAP2420 in omap2plus_defconfig (I made a
> patch for this) turning it
> into an omap3plus_defconfig as you say
>
> or
>
> - Actually add a new defconfig named omap3plus_defconfig
> with highmem enabled but SOC_OMAP2420 disabled.
>
> I don't know which option is the lesser evil ... it's a bit hairy.
>
> (A third option would be to reexamine runtime restriction options...)
Or actually using kmap_local_page() in mmc_omap_xfer_data(),
as Christoph suggested.
Arnd
