Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Markos Chandras <markos.chandras@imgtec.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: <linux-mips@linux-mips.org>
Subject: Re: [PATCH 3/4] MIPS: cpu-probe: Set the write-combine CCA value on per core basis
Date: Tue, 12 Aug 2014 08:23:53 +0100	[thread overview]
Message-ID: <20140812072353.GC12230@mchandras-linux.le.imgtec.org> (raw)
In-Reply-To: <53E00F39.7@gmail.com>

Hi Florian,

On Mon, Aug 04, 2014 at 03:54:49PM -0700, Florian Fainelli wrote:
> Hi Markos,
> 
> On 07/18/2014 02:51 AM, Markos Chandras wrote:
> > Different cores use different CCA values to achieve write-combine
> > memory writes. For cores that do not support write-combine we
> > set the default value to CCA:2 (uncached, non-coherent) which is the
> > default value as set by the kernel.
> > 
> > Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> > ---
> [snip]
> 			break;
> > @@ -765,67 +767,83 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
> >  
> >  static inline void cpu_probe_mips(struct cpuinfo_mips *c, unsigned int cpu)
> >  {
> > +	c->writecombine = _CACHE_UNCACHED_ACCELERATED;
> 
> Why do we set this writecombine setting by default, when later we are
> going to override writecombine on a per-cpu basic.
> 
> In the end, we have the following:
> 
> cpu_probe()
> 	c->writecombine = _CACHE_UNCACHED;
> 
> 	cpu_probe_mips()
> 		c->writecombine = _CACHE_UNCACHED_ACCELERATED:
> 		... per-cpu case ...
> 		c->writecombine = _CACHE_UNCACHED;
> 
> Can't we just eliminate the various assignments in cpu_probe_mips() and
> only override c->writecombine if _CACHE_UNCACHED is not suitable?
> 
The reason I did it like this, is that new cores (eg *Aptiv family) will use
_CACHE_UNCACHED_ACCELERATED and that's why it's the 'default' option for
the MIPS cores. _CACHE_UNCACHED is only suitable for old cores.
The way it is right now, allows us to not have to set this option whenever we
add support for a new core since it will inherit the default option.

-- 
markos

WARNING: multiple messages have this Message-ID (diff)
From: Markos Chandras <markos.chandras@imgtec.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 3/4] MIPS: cpu-probe: Set the write-combine CCA value on per core basis
Date: Tue, 12 Aug 2014 08:23:53 +0100	[thread overview]
Message-ID: <20140812072353.GC12230@mchandras-linux.le.imgtec.org> (raw)
Message-ID: <20140812072353._SG-d_2AbrjuJeHT1yWlpXKz9qGC-Ych-Pa5Uq0EEPw@z> (raw)
In-Reply-To: <53E00F39.7@gmail.com>

Hi Florian,

On Mon, Aug 04, 2014 at 03:54:49PM -0700, Florian Fainelli wrote:
> Hi Markos,
> 
> On 07/18/2014 02:51 AM, Markos Chandras wrote:
> > Different cores use different CCA values to achieve write-combine
> > memory writes. For cores that do not support write-combine we
> > set the default value to CCA:2 (uncached, non-coherent) which is the
> > default value as set by the kernel.
> > 
> > Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> > ---
> [snip]
> 			break;
> > @@ -765,67 +767,83 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
> >  
> >  static inline void cpu_probe_mips(struct cpuinfo_mips *c, unsigned int cpu)
> >  {
> > +	c->writecombine = _CACHE_UNCACHED_ACCELERATED;
> 
> Why do we set this writecombine setting by default, when later we are
> going to override writecombine on a per-cpu basic.
> 
> In the end, we have the following:
> 
> cpu_probe()
> 	c->writecombine = _CACHE_UNCACHED;
> 
> 	cpu_probe_mips()
> 		c->writecombine = _CACHE_UNCACHED_ACCELERATED:
> 		... per-cpu case ...
> 		c->writecombine = _CACHE_UNCACHED;
> 
> Can't we just eliminate the various assignments in cpu_probe_mips() and
> only override c->writecombine if _CACHE_UNCACHED is not suitable?
> 
The reason I did it like this, is that new cores (eg *Aptiv family) will use
_CACHE_UNCACHED_ACCELERATED and that's why it's the 'default' option for
the MIPS cores. _CACHE_UNCACHED is only suitable for old cores.
The way it is right now, allows us to not have to set this option whenever we
add support for a new core since it will inherit the default option.

-- 
markos

  reply	other threads:[~2014-08-12  7:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18  9:51 [PATCH 0/4] Add pgprot_writecombine function for MIPS Markos Chandras
2014-07-18  9:51 ` Markos Chandras
2014-07-18  9:51 ` [PATCH 1/4] MIPS: pgtable-bits: Move the CCA bits out of the core's ifdef blocks Markos Chandras
2014-07-18  9:51   ` Markos Chandras
2014-07-18  9:51 ` [PATCH 2/4] MIPS: pgtable-bits: Define the CCA bit for WC writes on Ingenic cores Markos Chandras
2014-07-18  9:51   ` Markos Chandras
2014-07-18  9:51 ` [PATCH 3/4] MIPS: cpu-probe: Set the write-combine CCA value on per core basis Markos Chandras
2014-07-18  9:51   ` Markos Chandras
2014-08-04 22:54   ` Florian Fainelli
2014-08-12  7:23     ` Markos Chandras [this message]
2014-08-12  7:23       ` Markos Chandras
2014-08-12 18:02       ` Florian Fainelli
2014-07-18  9:51 ` [PATCH 4/4] MIPS: pgtable.h: Implement the pgprot_writecombine function for MIPS Markos Chandras
2014-07-18  9:51   ` Markos Chandras
2014-08-27 11:16 ` [PATCH 0/4] Add " Ralf Baechle

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=20140812072353.GC12230@mchandras-linux.le.imgtec.org \
    --to=markos.chandras@imgtec.com \
    --cc=f.fainelli@gmail.com \
    --cc=linux-mips@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox