All of lore.kernel.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: apatel@ventanamicro.com, Paul Walmsley <paul.walmsley@sifive.com>,
	atishp@atishpatra.org, heiko@sntech.de, anup@brainfault.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	mchitale@ventanamicro.com
Subject: Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt
Date: Fri, 23 Sep 2022 03:45:49 -0700 (PDT)	[thread overview]
Message-ID: <mhng-9fd8dd19-53a3-426d-9d1e-3093ea6034fe@palmer-ri-x1c9> (raw)
In-Reply-To: <45de6e04-b19b-4ffe-878e-6ba8123f2aef@www.fastmail.com>

On Fri, 23 Sep 2022 03:35:50 PDT (-0700), Arnd Bergmann wrote:
> On Thu, Sep 22, 2022, at 6:35 PM, Palmer Dabbelt wrote:
>> On Thu, 15 Sep 2022 19:24:55 PDT (-0700), apatel@ventanamicro.com wrote:
>>>
>>> On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@ventanamicro.com> wrote:
>>>>
>>>> Currently, all flavors of ioremap_xyz() function maps to the generic
>>>> ioremap() which means any ioremap_xyz() call will always map the
>>>> target memory as IO using _PAGE_IOREMAP page attributes. This breaks
>>>> ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory
>>>> remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP
>>>> page attributes.
>>>>
>>>> To address above (just like other architectures), we implement RISC-V
>>>> specific ioremap_cache() and ioremap_wc() which maps memory using page
>>>> attributes as defined by the Svpbmt specification.
>>>>
>>>> Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support")
>>>> Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com>
>>>> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
>>>> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
>>>
>>> This is a crucial RC fix. Can you please take this ?
>>
>> Sorry I missed this, I thought it was just part of the rest of this
>> patch set.  That said, I'm not actually sure this is a critical fix:
>> sure it's a performance problem, and if some driver is expecting
>> ioremap_cache() to go fast then possibly a pretty big one, but the only
>> Svpmbt hardware that exists is the D1 and that was just supported this
>> release so it's not a regression.  Maybe that's a bit pedantic, but all
>> this travel has kind of made things a mess and I'm trying to make sure
>> nothing goes off the rails.
>
> I think generally speaking any use of ioremap_cache() in a driver
> is a mistake. The few users that exist are usually from historic
> x86 specific code and are hard to kill off.

Should we just add some sort of CONFIG_ARCH_HAS_IOREMAP_CACHE and then 
ban those drivers from everywhere else?

WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@dabbelt.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: apatel@ventanamicro.com, Paul Walmsley <paul.walmsley@sifive.com>,
	atishp@atishpatra.org, heiko@sntech.de, anup@brainfault.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	mchitale@ventanamicro.com
Subject: Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt
Date: Fri, 23 Sep 2022 03:45:49 -0700 (PDT)	[thread overview]
Message-ID: <mhng-9fd8dd19-53a3-426d-9d1e-3093ea6034fe@palmer-ri-x1c9> (raw)
In-Reply-To: <45de6e04-b19b-4ffe-878e-6ba8123f2aef@www.fastmail.com>

On Fri, 23 Sep 2022 03:35:50 PDT (-0700), Arnd Bergmann wrote:
> On Thu, Sep 22, 2022, at 6:35 PM, Palmer Dabbelt wrote:
>> On Thu, 15 Sep 2022 19:24:55 PDT (-0700), apatel@ventanamicro.com wrote:
>>>
>>> On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@ventanamicro.com> wrote:
>>>>
>>>> Currently, all flavors of ioremap_xyz() function maps to the generic
>>>> ioremap() which means any ioremap_xyz() call will always map the
>>>> target memory as IO using _PAGE_IOREMAP page attributes. This breaks
>>>> ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory
>>>> remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP
>>>> page attributes.
>>>>
>>>> To address above (just like other architectures), we implement RISC-V
>>>> specific ioremap_cache() and ioremap_wc() which maps memory using page
>>>> attributes as defined by the Svpbmt specification.
>>>>
>>>> Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support")
>>>> Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com>
>>>> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
>>>> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
>>>
>>> This is a crucial RC fix. Can you please take this ?
>>
>> Sorry I missed this, I thought it was just part of the rest of this
>> patch set.  That said, I'm not actually sure this is a critical fix:
>> sure it's a performance problem, and if some driver is expecting
>> ioremap_cache() to go fast then possibly a pretty big one, but the only
>> Svpmbt hardware that exists is the D1 and that was just supported this
>> release so it's not a regression.  Maybe that's a bit pedantic, but all
>> this travel has kind of made things a mess and I'm trying to make sure
>> nothing goes off the rails.
>
> I think generally speaking any use of ioremap_cache() in a driver
> is a mistake. The few users that exist are usually from historic
> x86 specific code and are hard to kill off.

Should we just add some sort of CONFIG_ARCH_HAS_IOREMAP_CACHE and then 
ban those drivers from everywhere else?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2022-09-23 10:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30  4:46 [PATCH v2 0/4] Add PMEM support for RISC-V Anup Patel
2022-08-30  4:46 ` Anup Patel
2022-08-30  4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel
2022-08-30  4:46   ` Anup Patel
2022-09-01 15:25   ` Heiko Stübner
2022-09-01 15:25     ` Heiko Stübner
2022-09-01 16:07   ` Conor.Dooley
2022-09-01 16:07     ` Conor.Dooley
2022-09-09  8:10   ` Anup Patel
2022-09-09  8:10     ` Anup Patel
2022-09-16  2:24   ` Anup Patel
2022-09-16  2:24     ` Anup Patel
2022-09-22 16:35     ` Palmer Dabbelt
2022-09-22 16:35       ` Palmer Dabbelt
2022-09-23 10:35       ` Arnd Bergmann
2022-09-23 10:35         ` Arnd Bergmann
2022-09-23 10:45         ` Palmer Dabbelt [this message]
2022-09-23 10:45           ` Palmer Dabbelt
2022-09-28 12:14       ` Christoph Hellwig
2022-09-28 12:14         ` Christoph Hellwig
2022-10-07  3:50         ` Palmer Dabbelt
2022-10-07  3:50           ` Palmer Dabbelt
2022-10-07  5:34           ` Anup Patel
2022-10-07  5:34             ` Anup Patel
2022-08-30  4:46 ` [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c Anup Patel
2022-08-30  4:46   ` Anup Patel
2022-09-01 15:29   ` Heiko Stübner
2022-09-01 15:29     ` Heiko Stübner
2022-09-01 15:49     ` Conor.Dooley
2022-09-01 15:49       ` Conor.Dooley
2022-08-30  4:46 ` [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs Anup Patel
2022-08-30  4:46   ` Anup Patel
2022-09-01 15:38   ` Heiko Stübner
2022-09-01 15:38     ` Heiko Stübner
2022-09-03 16:03     ` Anup Patel
2022-09-03 16:03       ` Anup Patel
2022-08-30  4:46 ` [PATCH v2 4/4] RISC-V: Enable PMEM drivers Anup Patel
2022-08-30  4:46   ` Anup Patel
2022-09-01 16:11   ` Conor.Dooley
2022-09-01 16:11     ` Conor.Dooley

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=mhng-9fd8dd19-53a3-426d-9d1e-3093ea6034fe@palmer-ri-x1c9 \
    --to=palmer@dabbelt.com \
    --cc=anup@brainfault.org \
    --cc=apatel@ventanamicro.com \
    --cc=arnd@arndb.de \
    --cc=atishp@atishpatra.org \
    --cc=heiko@sntech.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mchitale@ventanamicro.com \
    --cc=paul.walmsley@sifive.com \
    /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.