On Fri, Sep 09, 2016 at 06:17:13AM -0700, Sagar Borikar wrote:

Thanks James.

On Fri, Sep 9, 2016 at 5:36 AM, James Hogan [off-list ref] wrote:

quoted

Hi Sagar,

On Thu, Sep 08, 2016 at 08:33:57PM -0700, Sagar Borikar wrote:

quoted

Hello,

I am upgrading kernel for a MIPS Interaptive CPU from 3.10.60 to
3.14.10 (stable) from:
https://www.linux-mips.org/wiki/Malta_Linux_Repository

Unfortunately that wiki page needs updating.

If you're upgrading anyway, I think we'd recommend switching all the way
to a recent mainline kernel release / stable branch, e.g. 4.4 (LTS) or
4.7 (and maybe update to 4.9 (LTS) when it is released or when 4.7 goes
EOL). I think all the stuff you'll need for interAptiv should be in
mainline now anyway.

I see. We generally upgrade to malta repo as its maintained by mips
(imgtec). I presume you are referring to kernel.org. I think linux-mti
is having  4.1.7 as stable, right?

Yeh I was referring to kernel.org. 3.14 was the last linux-mti branch.
A lot of stuff in mti-3.10 got upstreamed (with a lot of changes and
clean ups made along the way), and I think as a result mti-3.14 was
mostly backported patches from mainline. That may explain this
regression.

We're now trying to focus a lot more on mainline (although we have
engineering branches in that same linux-mti repository, which are more
for supporting new architecture features & new cores before they've
found their way into mainline).

quoted

quoted

 The platform has non-contiguous low memory and high memory. After the
upgrade, highmem is not getting enabled due to max_low_pfn and
highend_pfn not being the same.

The commit cce335ae47e231398269fb05fa48e0e9cbf289e0 introduced the
change apparently for sibyte platform. That change doesn't hold good
for all platforms where the high memory and low memory is sparsed.

If I comment out only following change in arch/mips/mm/init.c, highmem
gets initialized properly.

296     if (cpu_has_dc_aliases && max_low_pfn != highend_pfn) {
297         printk(KERN_WARNING "This processor doesn't support highmem."
298                " %ldk highmem ignored\n",
299                (highend_pfn - max_low_pfn) << (PAGE_SHIFT - 10));
300         max_zone_pfns[ZONE_HIGHMEM] = max_low_pfn;
301         lastpfn = max_low_pfn;
302     }

I don't think we ever supported DCache aliasing + highmem in
combination.

Interesting. We are currently running 3.10.60 and apparently it seems
to work. Are you saying it may cause any issues? So far we haven't
seen any problems. What kind of issues it might end up into?

Sorry, I was thinking of mainline.

Mti-3.10 seems to have had changes which didn't make it upstream which
would have made this possible, from which commit 15de36a4c3cf
("mm/highmem: make kmap cache coloring aware") was derived (which was
merged for v3.17, in August 2014). There were attempts to add the MIPS
support after this, but none of them made it upstream:

https://patchwork.linux-mips.org/project/linux-mips/list/?state=*&q=fixes+for+cache+aliasing

quoted

If you want to use that memory your options are probably:
- increase the page size to avoid dcache aliasing.

Ok thanks. I would need to experiment with this but I am bit baffled
how its working in 3.10.60.
Generally, is there any reference platforms based on interaptiv which
uses highmem and dcache aliasing? I might have missed but couldn't
find any platform which comes close in both trees.

Its probably possible to configure malta in such a way (4k pages, big
cache, alias removal disabled in hardware, highmem).

quoted

- OR use EVA to increase the size of lowmem, which at the moment is a
  bit more involved. How much RAM do you have, and what does your
  physical memory map look like?

Total memory is 2GB. memory map looks like this:

low mem(~66MB) :

 * 0x04300000 +-----------------+
 *                    |     Linux       |
 * 0x00043000 +-----------------+

high mem (128MB):

 * 0x28000000 +-----------------+
 *                   |     linuxhi     |
 * 0x20000000 +-----------------+

Rest of the blocks are reserved.

It should be possible to use EVA to expand lowmem to cover these two
regions. Fitting in the whole 2GB would probably be a little trickier
depending on other stuff (how much IO memory is needed, IOCU in use,
etc).

Cheers
James