From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 4/4] ARM: mvebu: implement L2/PCIe deadlock workaround
Date: Tue, 13 May 2014 14:52:05 +0200 [thread overview]
Message-ID: <20140513145205.1dad280f@free-electrons.com> (raw)
In-Reply-To: <11503675.BOHdnE4xD3@wuerfel>
Dear Arnd Bergmann,
On Tue, 13 May 2014 13:13:39 +0200, Arnd Bergmann wrote:
> Hmm, I think this needs some more explanation about which flags
> you are actually interested in.
>
> These are the three common mem types for ioremap:
>
> #define PROT_PTE_DEVICE L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
> #define PROT_SECT_DEVICE PMD_TYPE_SECT|PMD_SECT_AP_WRITE
>
> [MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
> .prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
> L_PTE_SHARED,
> .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
> s2_policy(L_PTE_S2_MT_DEV_SHARED) |
> L_PTE_SHARED,
> .prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
> .domain = DOMAIN_IO,
> },
> [MT_DEVICE_CACHED] = { /* ioremap_cached */
> .prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_CACHED,
> .prot_sect = PROT_SECT_DEVICE | PMD_SECT_WB,
> .domain = DOMAIN_IO,
> },
> [MT_DEVICE_WC] = { /* ioremap_wc */
> .prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_WC,
> .prot_sect = PROT_SECT_DEVICE,
> .domain = DOMAIN_IO,
> },
>
> and this is the one you enforce here:
>
> [MT_MEMORY_RW_SO] = {
> .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
> L_PTE_MT_UNCACHED | L_PTE_XN,
> .prot_l1 = PMD_TYPE_TABLE,
> .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_S |
> PMD_SECT_UNCACHED | PMD_SECT_XN,
> .domain = DOMAIN_KERNEL,
> },
>
> So you set a different domain, and turn write-combined and cached mappings
> into uncached mappings, and for uncached mappings you remove the "shared"
> flag. Which of these changes is the one you actually need?
I *believe* the important part is the change from L_PTE_MT_DEV_SHARED
to L_PTE_MT_UNCACHED, because:
#define L_PTE_MT_UNCACHED (_AT(pteval_t, 0x00) << 2)
#define L_PTE_MT_DEV_SHARED (_AT(pteval_t, 0x04) << 2)
So the former is "Strongly-Ordered" according to the ARM ARM, while the
latter is "Device Shareable".
The only detail I have access to is that the workaround is "Reads
targeting PCIe End Point must be marked Strongly Ordered", so it's
pretty limited in details.
Do you think I should create a different memory type MT_DEVICE_SO, that
remains in the DOMAIN_IO domain, but uses L_PTE_MT_UNCACHED instead of
L_PTE_MT_DEV_SHARED ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-05-13 12:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 10:10 [PATCHv2 0/4] ARM: implement workaround for Cortex-A9/PL310/PCIe deadlock Thomas Petazzoni
2014-05-13 10:10 ` [PATCHv2 1/4] of: make of_update_property() usable earlier in the boot process Thomas Petazzoni
2014-05-13 14:00 ` Rob Herring
2014-05-13 14:30 ` Thomas Petazzoni
2014-05-13 14:54 ` Grant Likely
2014-05-13 15:30 ` Jason Cooper
2014-05-13 15:54 ` Thomas Petazzoni
2014-05-13 16:31 ` Jason Cooper
2014-05-13 16:58 ` Rob Herring
2014-05-13 17:00 ` Jason Cooper
2014-05-13 10:10 ` [PATCHv2 2/4] ARM: mm: allow sub-architectures to override PCI I/O memory type Thomas Petazzoni
2014-05-14 15:01 ` Catalin Marinas
2014-05-13 10:10 ` [PATCHv2 3/4] ARM: mm: add support for HW coherent systems in PL310 Thomas Petazzoni
2014-05-14 14:34 ` Catalin Marinas
2014-05-14 14:58 ` Thomas Petazzoni
2014-05-13 10:10 ` [PATCHv2 4/4] ARM: mvebu: implement L2/PCIe deadlock workaround Thomas Petazzoni
2014-05-13 11:13 ` Arnd Bergmann
2014-05-13 12:52 ` Thomas Petazzoni [this message]
2014-05-14 15:24 ` Catalin Marinas
2014-05-14 14:58 ` Catalin Marinas
2014-05-14 15:04 ` Thomas Petazzoni
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=20140513145205.1dad280f@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).