All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration
Date: Fri, 18 Sep 2015 08:34:17 +0200	[thread overview]
Message-ID: <20150918063417.GB13992@amd> (raw)
In-Reply-To: <55FBAE16.8050809@denx.de>

Hi!

> >>With this patch:
> >>=> tftp 100000 big-40mb
> >>Speed: 1000, full duplex
> >>Using dwmac.ff702000 device
> >>TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> >>Filename 'big-40mb'.
> >>Load address: 0x100000
> >>Loading: #################################################################
> >>          #################################################################
> >>          #################################################################
> >>          #################################################################
> >>          ##########################
> >>          7.6 MiB/s
> >>
> >>A performance improvement of factor ~3.
> >
> >Ok, so you turn on write-back cache and it is faster.
> 
> Its not only faster. My tests have shown, that the current implementation
> (WRITEALLOC) does not enable the dcache at all. No performance difference
> with dcache enable or disabled. I also tested this by removing the dcache
> flush and invalidate calls from the ethernet driver. And tftp still worked
> without any problems (same slow speed of course) with dcache enabled. On
> platforms with a really enabled dcache, such a change leads to a non-working
> network interface.

Yes, so we were running with dcache disabled, which can mask _many_
programming errors.

> >Now... do you have an explanation why this is safe to do? Are there
> >cache flushes that need to be added to the code now that we turned on
> >write-back?
> 
> I have not found any issues yet with this patch added. The cache handling
> calls (flush, invalidate) are already included in the code using it (e.g.
> USB, ethernet, MMC).

For generic code, you are right.

What about socfpga-specific code? Will this still do the right thing
with cache enabled? Do we have hardware registers mapped uncacheable?

Ok, I guess we should enable the cache and fix any bugs currently
hidden.

Best regards,
								Pavel

/* Toggle reset signal to watchdog (WDT is disabled after this
operation!) */
void socfpga_watchdog_reset(void)
{
        /* assert reset for watchdog */
	setbits_le32(&reset_manager_base->per_mod_reset,
		                     1 << RSTMGR_PERMODRST_L4WD0_LSB);

        /* deassert watchdog from reset (watchdog in not running
        state) */
	clrbits_le32(&reset_manager_base->per_mod_reset,
		                     1 << RSTMGR_PERMODRST_L4WD0_LSB);
 }
				     				     

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2015-09-18  6:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17 15:30 [U-Boot] [PATCH] arm: socfpga: Fix cache configuration Stefan Roese
2015-09-17 15:37 ` Marek Vasut
2015-09-18  6:16 ` Pavel Machek
2015-09-18  6:24   ` Stefan Roese
2015-09-18  6:34     ` Pavel Machek [this message]
2015-09-18  6:41       ` Stefan Roese
2015-11-09  0:10 ` Marek Vasut
2015-11-09 11:42   ` Stefan Roese
2015-11-09 13:49     ` Marek Vasut
2015-11-09 15:46       ` Stefan Roese
2015-11-09 16:02         ` Marek Vasut
2015-11-12  0:49           ` Chin Liang See
2015-11-12  0:53             ` Marek Vasut
2015-11-12  2:33               ` Chin Liang See
2015-11-12  3:48                 ` Marek Vasut
2015-12-03  0:10                 ` Marek Vasut
2015-12-03 16:11                   ` Chin Liang See
2015-12-03 16:22                     ` Marek Vasut
2015-12-07 14:37                       ` Chin Liang See
2015-12-07 14:44                         ` Marek Vasut
2015-12-07 14:47                           ` Chin Liang See
2015-12-08 11:13                           ` Pavel Machek
2015-12-08 12:04                             ` Stefan Roese
2015-12-08 12:54                               ` Marek Vasut
2015-12-09 13:48                                 ` Chin Liang See
2015-12-09 14:12                                   ` Marek Vasut
2015-12-08 12:53                             ` Marek Vasut
2015-12-09 13:50                               ` Chin Liang See

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=20150918063417.GB13992@amd \
    --to=pavel@denx.de \
    --cc=u-boot@lists.denx.de \
    /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.