public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Linus Walleij" <linus.walleij@linaro.org>
Cc: "Christoph Hellwig" <hch@lst.de>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Jens Axboe" <axboe@kernel.dk>, "Ming Lei" <ming.lei@redhat.com>,
	linux-block@vger.kernel.org,
	"linux-mmc @ vger . kernel . org" <linux-mmc@vger.kernel.org>
Subject: Re: mmc vs highmem, was: Re: [PATCH 2/2] blk-mq: ensure a q_usage_counter reference is held when splitting bios
Date: Wed, 24 Jan 2024 17:35:40 +0100	[thread overview]
Message-ID: <215c8e8e-8aee-411b-9f72-6ae40814c73d@app.fastmail.com> (raw)
In-Reply-To: <CACRpkdZKwHdPsR8KoyrhDjihLKiP5GdEgtYi_p-7L8b4_Ty_gg@mail.gmail.com>

On Wed, Jan 24, 2024, at 14:49, Linus Walleij wrote:
> On Mon, Jan 22, 2024 at 10:26 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
>> I found five drivers that have a legacy platform device
>> definition without a DMA mask:
>>
>> arch/m68k/coldfire/device.c: "sdhci-esdhc-mcf"
>> arch/arm/mach-omap1/devices.c: "mmci-omap" (slave DMA)
>> arch/sh/boards/board-sh7757lcr.c: "sh_mmcif" (slave DMA)
>> arch/sh/boards/mach-ecovec24/setup.c: sh_mmcif" (slave DMA)
>> arch/sh/boards/mach-*/setup.c: "sh_mobile_sdhi" (slave DMA)
>> drivers/misc/cb710/core.c: "cb710-mmc" (pio-only)
>>
>> None of these embedded platforms actually have highmem,
>> though the omap1 machine may run a kernel that has highmem
>> support enabled.
>>
>> Most of the others only support DT based probing after we
>> removed a lot of old board files a year ago, so they will
>> always have a 32-bit mask set at probe time.
>
> For sh_mmcif I just added dma_mask and coherent_dma_mask
> as DMA_BIT_MASK(32) in the boardfile

I think technically it's wrong to set the DMA mask
for the sh_mmcif device. The mask is set correctly
for the dmaengine driver, which is used correctly in

        ret = dma_map_sg(chan->device->dev, sg, data->sg_len,
                         DMA_FROM_DEVICE);

Since SH never has highmem, I don't think there is
anything that needs to be done for these.

Also for cb710, there is no DMA, and highmem gets
handled correctly through using sg_miter_next() etc.

> and I consider doing it
> for pretty much all of them: If they
> - Run without HIGHMEM enabled and
> - With highmem are bouncing buffers around to PKMAP (right?) when
>   BLK_BOUNCE_HIGH is set

> That kind of indicates that they are
> probably 32bit DMA capable, pretty much as the device trees
> assumes in most cases.

> This avoids doing Kconfig trickery, make it runtime handled
> and we can delete BLK_BOUNCE_HIGH as that branch is
> never taken and just refuse to probe if dma_mask == 0.

We can probably treat this as two different issues now:

a) drivers that don't set a DMA mask get the block layer
   bounce buffers, and as far as I can tell none of these
   actually need the bounce buffers, so we can already
   remove the BLK_BOUNCE_HIGH setting without causing
   a chance in behavior. cb710 is likely to see a
   small performance improvement when used on highmem
   systems without BLK_BOUNCE_HIGH but it's a very slow
   and old device, so nobody will notice

b) drivers that use sg_virt() instead of kmap_local_page()
   or sg_iter are currently broken if they run on on
   systems using highmem, as there is no bounce buffer
   when the DMA mask is set. Some of these may have
   used BLK_BOUNCE_HIGH in the past before the conversion
   to DT probing.

It's the second point that requires the Kconfig dependency.

      Arnd

  reply	other threads:[~2024-01-24 16:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 13:57 ensure q_usage_counter is held over bio splits Christoph Hellwig
2024-01-11 13:57 ` [PATCH 1/2] blk-mq: rename blk_mq_can_use_cached_rq Christoph Hellwig
2024-01-11 13:57 ` [PATCH 2/2] blk-mq: ensure a q_usage_counter reference is held when splitting bios Christoph Hellwig
2024-01-11 16:12   ` Jens Axboe
2024-01-11 16:14     ` Christoph Hellwig
2024-01-11 16:17       ` Jens Axboe
2024-01-11 16:18         ` Christoph Hellwig
2024-01-11 17:10         ` Christoph Hellwig
2024-01-11 17:18           ` Jens Axboe
2024-01-11 17:24             ` Christoph Hellwig
2024-01-11 20:06               ` Jens Axboe
2024-01-12  5:44                 ` Christoph Hellwig
2024-01-12 14:22                   ` Jens Axboe
2024-01-12 14:25                     ` Christoph Hellwig
2024-01-12 16:10                       ` Jens Axboe
2024-01-15 11:20                     ` Ulf Hansson
2024-01-22  7:34                       ` mmc vs highmem, was: " Christoph Hellwig
2024-01-22  9:26                         ` Arnd Bergmann
2024-01-22 13:39                           ` Christoph Hellwig
2024-01-22 14:57                             ` Arnd Bergmann
2024-01-23  9:11                               ` Christoph Hellwig
2024-01-24 11:59                                 ` Arnd Bergmann
2024-01-24 12:33                                   ` Linus Walleij
2024-01-24 12:54                                     ` Arnd Bergmann
2024-01-24 13:16                                       ` Linus Walleij
2024-01-24 14:14                                         ` Arnd Bergmann
2024-01-24 12:45                               ` Arnd Bergmann
2024-01-24 13:49                           ` Linus Walleij
2024-01-24 16:35                             ` Arnd Bergmann [this message]
2024-01-11 22:22   ` Ming Lei
2024-01-12  5:46     ` Christoph Hellwig
2024-01-11 16:03 ` ensure q_usage_counter is held over bio splits Jens Axboe
2024-01-14 14:38 ` (subset) " Jens Axboe

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=215c8e8e-8aee-411b-9f72-6ae40814c73d@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=ulf.hansson@linaro.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