All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <florian@openwrt.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
	blogic@openwrt.org
Subject: Re: [PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value
Date: Sun, 23 Mar 2014 12:01:31 -0700	[thread overview]
Message-ID: <4353562.NNfMoORRNC@lenovo> (raw)
In-Reply-To: <alpine.LFD.2.10.1403230203410.21669@eddie.linux-mips.org>

Le dimanche 23 mars 2014, 02:16:27 Maciej W. Rozycki a écrit :
> On Tue, 21 Jan 2014, Florian Fainelli wrote:
> > When support for the DECStation is enabled, it will default to use a
> > MIPS R3000 class processor. This will cause an intentional build failure
> > to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size()
> > disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build
> > targetting a MIPS R3000 CPU to fix that build failure and satisfy all
> > requirements.
> 
>  Thanks for your contribution.  However I just built a pristine ToT LMO
> kernel for an R3000 DECstation and that went fine, I got no error.  Can
> you provide me with a way to reproduce the problem?

The build failure was only transient, in conjunction wit this patch applied:

http://www.linux-mips.org/archives/linux-mips/2014-01/msg00183.html

which was then reverted.

> 
>  I am not opposed to your change per se, it may make sense regardless.
> However using a value of MIPS_L1_CACHE_SHIFT that is too high results in
> wasting some memory, but should otherwise be safe I believe, so I'm not
> really convinced adding this config infrastructure is going to pay off.

Not quite sure what "infrastructure" you are referring to here.

MIPS_L1_CACHE_SHIFT_<N> is just a bunch of Kconfig symbols that platform can 
select, to avoid an ever-growing list of:

default 5 if MIPS_FOO && MIPS_BAR && MIPS_BAZ

I think that this patch is still applicable as it makes it more accurate which 
L1_CACHE_SHIFT_SIZE is really required for a given CPU configuration 
DECSstation, and will avoid overbooking that value when R3000 CPUs are 
configured/used specifically here.
-- 
Florian

  reply	other threads:[~2014-03-23 19:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-21 18:01 [PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2 Florian Fainelli
2014-01-21 18:01 ` Florian Fainelli
2014-01-21 18:01 ` [PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value Florian Fainelli
2014-01-21 18:01   ` Florian Fainelli
2014-03-23  2:16   ` Maciej W. Rozycki
2014-03-23 19:01     ` Florian Fainelli [this message]
2014-04-01  0:06   ` Maciej W. Rozycki
2014-06-01  8:31     ` Maciej W. Rozycki
2014-03-24 14:12 ` [PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2 Ralf Baechle
2014-03-24 16:20   ` Maciej W. Rozycki
2014-03-24 16:44     ` Florian Fainelli
2014-04-01  0:05 ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4353562.NNfMoORRNC@lenovo \
    --to=florian@openwrt.org \
    --cc=blogic@openwrt.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.