* [PATCH 0/2] mmc: renesas_sdhi: bugfixes for v4.14
@ 2017-10-17 7:30 Yoshihiro Shimoda
2017-10-17 7:30 ` [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full Yoshihiro Shimoda
2017-10-17 7:30 ` [PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c Yoshihiro Shimoda
0 siblings, 2 replies; 20+ messages in thread
From: Yoshihiro Shimoda @ 2017-10-17 7:30 UTC (permalink / raw)
To: wsa+renesas, ulf.hansson; +Cc: linux-mmc, linux-renesas-soc, Yoshihiro Shimoda
This patch set is based on mainline v4.14-rc5.
Yoshihiro Shimoda (2):
mmc: renesas_sdhi: fix swiotlb buffer is full
mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
--
1.9.1
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
2017-10-17 7:30 [PATCH 0/2] mmc: renesas_sdhi: bugfixes for v4.14 Yoshihiro Shimoda
@ 2017-10-17 7:30 ` Yoshihiro Shimoda
2017-10-17 8:02 ` Geert Uytterhoeven
2017-10-17 7:30 ` [PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c Yoshihiro Shimoda
1 sibling, 1 reply; 20+ messages in thread
From: Yoshihiro Shimoda @ 2017-10-17 7:30 UTC (permalink / raw)
To: wsa+renesas, ulf.hansson; +Cc: linux-mmc, linux-renesas-soc, Yoshihiro Shimoda
Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
deletes the bounce buffer handling, a request data size will be referred
to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
In other hand, renesas_sdhi_internal_dmac.c will set very big value of
max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
And then, "swiotlb buffer is full" happens because swiotlb can handle
a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
IO_TLB_SHIFT = 11).
So, this patch fixes the issue to set max_blk_count to 512. Then,
the max_{req,seg}_size will be set to 256k bytes.
Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index f905f23..6c9b4b2 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -80,8 +80,9 @@
.scc_offset = 0x1000,
.taps = rcar_gen3_scc_taps,
.taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
- /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
- .max_blk_count = 0xffffffff,
+ /* The swiotlb can handle memory size up to 256 kbytes for now. */
+ .max_blk_count = 512,
+ /* Gen3 SDHI DMAC cannot handle scatter-gather. So, max_segs = 1 */
.max_segs = 1,
};
--
1.9.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c
2017-10-17 7:30 [PATCH 0/2] mmc: renesas_sdhi: bugfixes for v4.14 Yoshihiro Shimoda
2017-10-17 7:30 ` [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full Yoshihiro Shimoda
@ 2017-10-17 7:30 ` Yoshihiro Shimoda
2017-10-17 8:11 ` Geert Uytterhoeven
1 sibling, 1 reply; 20+ messages in thread
From: Yoshihiro Shimoda @ 2017-10-17 7:30 UTC (permalink / raw)
To: wsa+renesas, ulf.hansson; +Cc: linux-mmc, linux-renesas-soc, Yoshihiro Shimoda
Since this driver checks if the return value of dma_map_sg() is minus
or not and keeps to enable the DMAC, it may cause kernel panic when
the dma_map_sg() returns 0. So, this patch fixes the issue.
Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 6c9b4b2..378fe88 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -147,11 +147,8 @@
WARN_ON(host->sg_len > 1);
/* This DMAC cannot handle if buffer is not 8-bytes alignment */
- if (!IS_ALIGNED(sg->offset, 8)) {
- host->force_pio = true;
- renesas_sdhi_internal_dmac_enable_dma(host, false);
- return;
- }
+ if (!IS_ALIGNED(sg->offset, 8))
+ goto force_pio;
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
@@ -164,8 +161,8 @@
}
ret = dma_map_sg(&host->pdev->dev, sg, host->sg_len, dir);
- if (ret < 0)
- return;
+ if (ret == 0)
+ goto force_pio;
renesas_sdhi_internal_dmac_enable_dma(host, true);
@@ -177,6 +174,12 @@
dtran_mode);
renesas_sdhi_internal_dmac_dm_write(host, DM_DTRAN_ADDR,
sg->dma_address);
+
+ return;
+
+force_pio:
+ host->force_pio = true;
+ renesas_sdhi_internal_dmac_enable_dma(host, false);
}
static void renesas_sdhi_internal_dmac_issue_tasklet_fn(unsigned long arg)
--
1.9.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-10-17 8:02 ` Geert Uytterhoeven
0 siblings, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2017-10-17 8:02 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Wolfram Sang, Ulf Hansson, Linux MMC List, Linux-Renesas, iommu
Hi Shimoda-san,
CC iommu
On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
> deletes the bounce buffer handling, a request data size will be referred
> to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
>
> In other hand, renesas_sdhi_internal_dmac.c will set very big value of
> max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
> And then, "swiotlb buffer is full" happens because swiotlb can handle
> a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
> IO_TLB_SHIFT = 11).
>
> So, this patch fixes the issue to set max_blk_count to 512. Then,
> the max_{req,seg}_size will be set to 256k bytes.
>
> Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Thanks for your patch!
> ---
> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index f905f23..6c9b4b2 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -80,8 +80,9 @@
> .scc_offset = 0x1000,
> .taps = rcar_gen3_scc_taps,
> .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> - .max_blk_count = 0xffffffff,
> + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> + .max_blk_count = 512,
Fixing this in the individual drivers feels like the wrong solution to me.
iommu: Is there a better (generic) way to handle this?
> + /* Gen3 SDHI DMAC cannot handle scatter-gather. So, max_segs = 1 */
> .max_segs = 1,
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-10-17 8:02 ` Geert Uytterhoeven
0 siblings, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2017-10-17 8:02 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Linux-Renesas, Wolfram Sang, Ulf Hansson, Linux MMC List,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Hi Shimoda-san,
CC iommu
On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
> deletes the bounce buffer handling, a request data size will be referred
> to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
>
> In other hand, renesas_sdhi_internal_dmac.c will set very big value of
> max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
> And then, "swiotlb buffer is full" happens because swiotlb can handle
> a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
> IO_TLB_SHIFT = 11).
>
> So, this patch fixes the issue to set max_blk_count to 512. Then,
> the max_{req,seg}_size will be set to 256k bytes.
>
> Reported-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Thanks for your patch!
> ---
> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index f905f23..6c9b4b2 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -80,8 +80,9 @@
> .scc_offset = 0x1000,
> .taps = rcar_gen3_scc_taps,
> .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> - .max_blk_count = 0xffffffff,
> + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> + .max_blk_count = 512,
Fixing this in the individual drivers feels like the wrong solution to me.
iommu: Is there a better (generic) way to handle this?
> + /* Gen3 SDHI DMAC cannot handle scatter-gather. So, max_segs = 1 */
> .max_segs = 1,
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c
2017-10-17 7:30 ` [PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c Yoshihiro Shimoda
@ 2017-10-17 8:11 ` Geert Uytterhoeven
0 siblings, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2017-10-17 8:11 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Wolfram Sang, Ulf Hansson, Linux MMC List, Linux-Renesas
Hi Shimoda-san,
On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> Since this driver checks if the return value of dma_map_sg() is minus
> or not and keeps to enable the DMAC, it may cause kernel panic when
> the dma_map_sg() returns 0. So, this patch fixes the issue.
Thanks for your patch!
Indeed:
* dma_maps_sg_attrs returns 0 on error and > 0 on success.
* It should never return a value < 0.
A quick grep shows there are 4 more offenders:
- drivers/crypto/qce/ablkcipher.c
- drivers/crypto/qce/sha.c
- drivers/hsi/controllers/omap_ssi_port.c
- drivers/mailbox/bcm-flexrm-mailbox.c
> Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
> Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC")
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-10-19 0:24 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 20+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-10-19 0:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Linux-Renesas, Wolfram Sang, Ulf Hansson,
Linux MMC List, iommu
On Tue, Oct 17, 2017 at 10:02:50AM +0200, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
>
> CC iommu
>
> On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
> > deletes the bounce buffer handling, a request data size will be referred
> > to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
> >
> > In other hand, renesas_sdhi_internal_dmac.c will set very big value of
> > max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
> > And then, "swiotlb buffer is full" happens because swiotlb can handle
> > a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
> > IO_TLB_SHIFT = 11).
> >
> > So, this patch fixes the issue to set max_blk_count to 512. Then,
> > the max_{req,seg}_size will be set to 256k bytes.
> >
> > Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> Thanks for your patch!
>
> > ---
> > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > index f905f23..6c9b4b2 100644
> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > @@ -80,8 +80,9 @@
> > .scc_offset = 0x1000,
> > .taps = rcar_gen3_scc_taps,
> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> > - .max_blk_count = 0xffffffff,
> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> > + .max_blk_count = 512,
>
> Fixing this in the individual drivers feels like the wrong solution to me.
>
> iommu: Is there a better (generic) way to handle this?
Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-10-19 0:24 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 20+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-10-19 0:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Linux MMC List, Linux-Renesas, Wolfram Sang,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
On Tue, Oct 17, 2017 at 10:02:50AM +0200, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
>
> CC iommu
>
> On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> > Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
> > deletes the bounce buffer handling, a request data size will be referred
> > to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
> >
> > In other hand, renesas_sdhi_internal_dmac.c will set very big value of
> > max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
> > And then, "swiotlb buffer is full" happens because swiotlb can handle
> > a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
> > IO_TLB_SHIFT = 11).
> >
> > So, this patch fixes the issue to set max_blk_count to 512. Then,
> > the max_{req,seg}_size will be set to 256k bytes.
> >
> > Reported-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Thanks for your patch!
>
> > ---
> > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > index f905f23..6c9b4b2 100644
> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > @@ -80,8 +80,9 @@
> > .scc_offset = 0x1000,
> > .taps = rcar_gen3_scc_taps,
> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> > - .max_blk_count = 0xffffffff,
> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> > + .max_blk_count = 512,
>
> Fixing this in the individual drivers feels like the wrong solution to me.
>
> iommu: Is there a better (generic) way to handle this?
Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-10-19 8:34 ` Geert Uytterhoeven
0 siblings, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2017-10-19 8:34 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Yoshihiro Shimoda, Linux-Renesas, Wolfram Sang, Ulf Hansson,
Linux MMC List, iommu
Hi Konrad,
On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Tue, Oct 17, 2017 at 10:02:50AM +0200, Geert Uytterhoeven wrote:
>> On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com> wrote:
>> > Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
>> > deletes the bounce buffer handling, a request data size will be referred
>> > to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
>> >
>> > In other hand, renesas_sdhi_internal_dmac.c will set very big value of
>> > max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
>> > And then, "swiotlb buffer is full" happens because swiotlb can handle
>> > a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
>> > IO_TLB_SHIFT = 11).
>> >
>> > So, this patch fixes the issue to set max_blk_count to 512. Then,
>> > the max_{req,seg}_size will be set to 256k bytes.
>> >
>> > Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
>> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>
>> Thanks for your patch!
>>
>> > ---
>> > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
>> > 1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
>> > index f905f23..6c9b4b2 100644
>> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
>> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
>> > @@ -80,8 +80,9 @@
>> > .scc_offset = 0x1000,
>> > .taps = rcar_gen3_scc_taps,
>> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
>> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
>> > - .max_blk_count = 0xffffffff,
>> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
>> > + .max_blk_count = 512,
>>
>> Fixing this in the individual drivers feels like the wrong solution to me.
>>
>> iommu: Is there a better (generic) way to handle this?
>
> Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
Thanks for the pointer!
While I agree this can be used to avoid the swiotlb buffer full issue,
I believe it is a suboptimal solution if the device actually uses an IOMMU.
It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
case for arm/arm64 these days.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-10-19 8:34 ` Geert Uytterhoeven
0 siblings, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2017-10-19 8:34 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ulf Hansson, Linux MMC List, Linux-Renesas, Wolfram Sang,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Hi Konrad,
On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
<konrad-Gq0aWv8utHQdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Oct 17, 2017 at 10:02:50AM +0200, Geert Uytterhoeven wrote:
>> On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
>> > Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
>> > deletes the bounce buffer handling, a request data size will be referred
>> > to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
>> >
>> > In other hand, renesas_sdhi_internal_dmac.c will set very big value of
>> > max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
>> > And then, "swiotlb buffer is full" happens because swiotlb can handle
>> > a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
>> > IO_TLB_SHIFT = 11).
>> >
>> > So, this patch fixes the issue to set max_blk_count to 512. Then,
>> > the max_{req,seg}_size will be set to 256k bytes.
>> >
>> > Reported-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
>> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>>
>> Thanks for your patch!
>>
>> > ---
>> > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
>> > 1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
>> > index f905f23..6c9b4b2 100644
>> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
>> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
>> > @@ -80,8 +80,9 @@
>> > .scc_offset = 0x1000,
>> > .taps = rcar_gen3_scc_taps,
>> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
>> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
>> > - .max_blk_count = 0xffffffff,
>> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
>> > + .max_blk_count = 512,
>>
>> Fixing this in the individual drivers feels like the wrong solution to me.
>>
>> iommu: Is there a better (generic) way to handle this?
>
> Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
Thanks for the pointer!
While I agree this can be used to avoid the swiotlb buffer full issue,
I believe it is a suboptimal solution if the device actually uses an IOMMU.
It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
case for arm/arm64 these days.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
2017-10-19 8:34 ` Geert Uytterhoeven
(?)
@ 2017-10-19 11:39 ` Yoshihiro Shimoda
2017-10-20 3:18 ` Yoshihiro Shimoda
-1 siblings, 1 reply; 20+ messages in thread
From: Yoshihiro Shimoda @ 2017-10-19 11:39 UTC (permalink / raw)
To: Geert Uytterhoeven, Konrad Rzeszutek Wilk
Cc: Linux-Renesas, Wolfram Sang, Ulf Hansson, Linux MMC List, iommu
Hi Geert-san, Konrad-san,
> From: Geert Uytterhoeven, Sent: Thursday, October 19, 2017 5:34 PM
>
> Hi Konrad,
>
> On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> > On Tue, Oct 17, 2017 at 10:02:50AM +0200, Geert Uytterhoeven wrote:
> >> On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda
> >> <yoshihiro.shimoda.uh@renesas.com> wrote:
> >> > Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling")
> >> > deletes the bounce buffer handling, a request data size will be referred
> >> > to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).
> >> >
> >> > In other hand, renesas_sdhi_internal_dmac.c will set very big value of
> >> > max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
> >> > And then, "swiotlb buffer is full" happens because swiotlb can handle
> >> > a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
> >> > IO_TLB_SHIFT = 11).
> >> >
> >> > So, this patch fixes the issue to set max_blk_count to 512. Then,
> >> > the max_{req,seg}_size will be set to 256k bytes.
> >> >
> >> > Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
> >> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >>
> >> Thanks for your patch!
> >>
> >> > ---
> >> > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +++--
> >> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> >> > index f905f23..6c9b4b2 100644
> >> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> >> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> >> > @@ -80,8 +80,9 @@
> >> > .scc_offset = 0x1000,
> >> > .taps = rcar_gen3_scc_taps,
> >> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> >> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> >> > - .max_blk_count = 0xffffffff,
> >> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> >> > + .max_blk_count = 512,
> >>
> >> Fixing this in the individual drivers feels like the wrong solution to me.
> >>
> >> iommu: Is there a better (generic) way to handle this?
> >
> > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
>
> Thanks for the pointer!
>
> While I agree this can be used to avoid the swiotlb buffer full issue,
> I believe it is a suboptimal solution if the device actually uses an IOMMU.
> It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
> case for arm/arm64 these days.
I'm afraid but I misunderstood this API's spec when I read it at first.
After I tried to use it, I found the API cannot be used for a workaround because
this API returns total size of swiotlb.
For example:
- The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
- In this case, the maximum size per a map is 256k bytes.
- The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
into the kernel parameter on arm64.
- In this case, the maximum size per a map is still 256k bytes because
the swiotlb has hardcoded the size by the following code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
So, how do we handle to resolve (or avoid) the issue?
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
2017-10-19 11:39 ` Yoshihiro Shimoda
@ 2017-10-20 3:18 ` Yoshihiro Shimoda
2017-11-01 13:26 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 20+ messages in thread
From: Yoshihiro Shimoda @ 2017-10-20 3:18 UTC (permalink / raw)
To: Geert Uytterhoeven, Konrad Rzeszutek Wilk
Cc: Linux-Renesas, Wolfram Sang, Ulf Hansson, Linux MMC List, iommu
Hi again!
> From: Yoshihiro Shimoda, Sent: Thursday, October 19, 2017 8:39 PM
>
> Hi Geert-san, Konrad-san,
>
> > From: Geert Uytterhoeven, Sent: Thursday, October 19, 2017 5:34 PM
> >
> > Hi Konrad,
> >
> > On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
> > <konrad@darnok.org> wrote:
< snip >
> > >> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > >> > index f905f23..6c9b4b2 100644
> > >> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > >> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > >> > @@ -80,8 +80,9 @@
> > >> > .scc_offset = 0x1000,
> > >> > .taps = rcar_gen3_scc_taps,
> > >> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> > >> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> > >> > - .max_blk_count = 0xffffffff,
> > >> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> > >> > + .max_blk_count = 512,
> > >>
> > >> Fixing this in the individual drivers feels like the wrong solution to me.
> > >>
> > >> iommu: Is there a better (generic) way to handle this?
> > >
> > > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
> >
> > Thanks for the pointer!
> >
> > While I agree this can be used to avoid the swiotlb buffer full issue,
> > I believe it is a suboptimal solution if the device actually uses an IOMMU.
> > It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
> > case for arm/arm64 these days.
>
> I'm afraid but I misunderstood this API's spec when I read it at first.
> After I tried to use it, I found the API cannot be used for a workaround because
> this API returns total size of swiotlb.
>
> For example:
> - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> - In this case, the maximum size per a map is 256k bytes.
> - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> into the kernel parameter on arm64.
> - In this case, the maximum size per a map is still 256k bytes because
> the swiotlb has hardcoded the size by the following code:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
>
> So, how do we handle to resolve (or avoid) the issue?
Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
https://patchwork.kernel.org/patch/10018879/
Best regards,
Yoshihiro Shimoda
> Best regards,
> Yoshihiro Shimoda
>
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
2017-10-20 3:18 ` Yoshihiro Shimoda
@ 2017-11-01 13:26 ` Konrad Rzeszutek Wilk
2017-11-02 4:10 ` Yoshihiro Shimoda
0 siblings, 1 reply; 20+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-11-01 13:26 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Geert Uytterhoeven, Konrad Rzeszutek Wilk, Linux-Renesas,
Wolfram Sang, Ulf Hansson, Linux MMC List, iommu
On Fri, Oct 20, 2017 at 03:18:55AM +0000, Yoshihiro Shimoda wrote:
> Hi again!
>
> > From: Yoshihiro Shimoda, Sent: Thursday, October 19, 2017 8:39 PM
> >
> > Hi Geert-san, Konrad-san,
> >
> > > From: Geert Uytterhoeven, Sent: Thursday, October 19, 2017 5:34 PM
> > >
> > > Hi Konrad,
> > >
> > > On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
> > > <konrad@darnok.org> wrote:
> < snip >
> > > >> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > >> > index f905f23..6c9b4b2 100644
> > > >> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > >> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > >> > @@ -80,8 +80,9 @@
> > > >> > .scc_offset = 0x1000,
> > > >> > .taps = rcar_gen3_scc_taps,
> > > >> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> > > >> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> > > >> > - .max_blk_count = 0xffffffff,
> > > >> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> > > >> > + .max_blk_count = 512,
> > > >>
> > > >> Fixing this in the individual drivers feels like the wrong solution to me.
> > > >>
> > > >> iommu: Is there a better (generic) way to handle this?
> > > >
> > > > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
> > >
> > > Thanks for the pointer!
> > >
> > > While I agree this can be used to avoid the swiotlb buffer full issue,
> > > I believe it is a suboptimal solution if the device actually uses an IOMMU.
> > > It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
> > > case for arm/arm64 these days.
> >
> > I'm afraid but I misunderstood this API's spec when I read it at first.
> > After I tried to use it, I found the API cannot be used for a workaround because
> > this API returns total size of swiotlb.
> >
> > For example:
> > - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> > - In this case, the maximum size per a map is 256k bytes.
> > - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> > into the kernel parameter on arm64.
> > - In this case, the maximum size per a map is still 256k bytes because
> > the swiotlb has hardcoded the size by the following code:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
> >
> > So, how do we handle to resolve (or avoid) the issue?
>
> Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
Did I miss that email? As in was I cc-ed?
> https://patchwork.kernel.org/patch/10018879/
Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
swiotlb_max_segment? See 5584f1b1d73e9
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-11-02 4:10 ` Yoshihiro Shimoda
0 siblings, 0 replies; 20+ messages in thread
From: Yoshihiro Shimoda @ 2017-11-02 4:10 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Geert Uytterhoeven, Konrad Rzeszutek Wilk, Linux-Renesas,
Wolfram Sang, Ulf Hansson, Linux MMC List, iommu
Hi,
> From: Konrad Rzeszutek, Sent: Wednesday, November 1, 2017 10:27 PM
>
> On Fri, Oct 20, 2017 at 03:18:55AM +0000, Yoshihiro Shimoda wrote:
> > Hi again!
> >
> > > From: Yoshihiro Shimoda, Sent: Thursday, October 19, 2017 8:39 PM
> > >
> > > Hi Geert-san, Konrad-san,
> > >
> > > > From: Geert Uytterhoeven, Sent: Thursday, October 19, 2017 5:34 PM
> > > >
> > > > Hi Konrad,
> > > >
> > > > On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
> > > > <konrad@darnok.org> wrote:
> > < snip >
> > > > >> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > > >> > index f905f23..6c9b4b2 100644
> > > > >> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > > >> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > > >> > @@ -80,8 +80,9 @@
> > > > >> > .scc_offset = 0x1000,
> > > > >> > .taps = rcar_gen3_scc_taps,
> > > > >> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> > > > >> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> > > > >> > - .max_blk_count = 0xffffffff,
> > > > >> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> > > > >> > + .max_blk_count = 512,
> > > > >>
> > > > >> Fixing this in the individual drivers feels like the wrong solution to me.
> > > > >>
> > > > >> iommu: Is there a better (generic) way to handle this?
> > > > >
> > > > > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
> > > >
> > > > Thanks for the pointer!
> > > >
> > > > While I agree this can be used to avoid the swiotlb buffer full issue,
> > > > I believe it is a suboptimal solution if the device actually uses an IOMMU.
> > > > It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
> > > > case for arm/arm64 these days.
> > >
> > > I'm afraid but I misunderstood this API's spec when I read it at first.
> > > After I tried to use it, I found the API cannot be used for a workaround because
> > > this API returns total size of swiotlb.
> > >
> > > For example:
> > > - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> > > - In this case, the maximum size per a map is 256k bytes.
> > > - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> > > into the kernel parameter on arm64.
> > > - In this case, the maximum size per a map is still 256k bytes because
> > > the swiotlb has hardcoded the size by the following code:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
> > >
> > > So, how do we handle to resolve (or avoid) the issue?
> >
> > Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
>
> Did I miss that email? As in was I cc-ed?
This was my fault. When I submitted v2 patches, I didn't include your email and iommu mailing list...
> > https://patchwork.kernel.org/patch/10018879/
>
> Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
> swiotlb_max_segment? See 5584f1b1d73e9
I already made such a patch as v2 and it was merged into mmc.git / fixes branch.
https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=e90e8da72ad694a16a4ffa6e5adae3610208f73b
Best regards,
Yoshihiro Shimoda
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-11-02 4:10 ` Yoshihiro Shimoda
0 siblings, 0 replies; 20+ messages in thread
From: Yoshihiro Shimoda @ 2017-11-02 4:10 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ulf Hansson, Linux MMC List, Linux-Renesas, Wolfram Sang,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Geert Uytterhoeven, Konrad Rzeszutek Wilk
Hi,
> From: Konrad Rzeszutek, Sent: Wednesday, November 1, 2017 10:27 PM
>
> On Fri, Oct 20, 2017 at 03:18:55AM +0000, Yoshihiro Shimoda wrote:
> > Hi again!
> >
> > > From: Yoshihiro Shimoda, Sent: Thursday, October 19, 2017 8:39 PM
> > >
> > > Hi Geert-san, Konrad-san,
> > >
> > > > From: Geert Uytterhoeven, Sent: Thursday, October 19, 2017 5:34 PM
> > > >
> > > > Hi Konrad,
> > > >
> > > > On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
> > > > <konrad-Gq0aWv8utHQdnm+yROfE0A@public.gmane.org> wrote:
> > < snip >
> > > > >> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > > >> > index f905f23..6c9b4b2 100644
> > > > >> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > > >> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > > >> > @@ -80,8 +80,9 @@
> > > > >> > .scc_offset = 0x1000,
> > > > >> > .taps = rcar_gen3_scc_taps,
> > > > >> > .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
> > > > >> > - /* Gen3 SDHI DMAC can handle 0xffffffff blk count, but seg = 1 */
> > > > >> > - .max_blk_count = 0xffffffff,
> > > > >> > + /* The swiotlb can handle memory size up to 256 kbytes for now. */
> > > > >> > + .max_blk_count = 512,
> > > > >>
> > > > >> Fixing this in the individual drivers feels like the wrong solution to me.
> > > > >>
> > > > >> iommu: Is there a better (generic) way to handle this?
> > > > >
> > > > > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
> > > >
> > > > Thanks for the pointer!
> > > >
> > > > While I agree this can be used to avoid the swiotlb buffer full issue,
> > > > I believe it is a suboptimal solution if the device actually uses an IOMMU.
> > > > It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
> > > > case for arm/arm64 these days.
> > >
> > > I'm afraid but I misunderstood this API's spec when I read it at first.
> > > After I tried to use it, I found the API cannot be used for a workaround because
> > > this API returns total size of swiotlb.
> > >
> > > For example:
> > > - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> > > - In this case, the maximum size per a map is 256k bytes.
> > > - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> > > into the kernel parameter on arm64.
> > > - In this case, the maximum size per a map is still 256k bytes because
> > > the swiotlb has hardcoded the size by the following code:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
> > >
> > > So, how do we handle to resolve (or avoid) the issue?
> >
> > Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
>
> Did I miss that email? As in was I cc-ed?
This was my fault. When I submitted v2 patches, I didn't include your email and iommu mailing list...
> > https://patchwork.kernel.org/patch/10018879/
>
> Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
> swiotlb_max_segment? See 5584f1b1d73e9
I already made such a patch as v2 and it was merged into mmc.git / fixes branch.
https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=e90e8da72ad694a16a4ffa6e5adae3610208f73b
Best regards,
Yoshihiro Shimoda
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
2017-11-02 4:10 ` Yoshihiro Shimoda
(?)
@ 2017-11-03 13:23 ` Konrad Rzeszutek Wilk
2017-11-03 14:01 ` Geert Uytterhoeven
-1 siblings, 1 reply; 20+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-11-03 13:23 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Geert Uytterhoeven, Konrad Rzeszutek Wilk, Linux-Renesas,
Wolfram Sang, Ulf Hansson, Linux MMC List, iommu
..snip..
> > >
> > > Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
> >
> > Did I miss that email? As in was I cc-ed?
>
> This was my fault. When I submitted v2 patches, I didn't include your email and iommu mailing list...
No problem.
>
> > > https://patchwork.kernel.org/patch/10018879/
> >
> > Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
> > swiotlb_max_segment? See 5584f1b1d73e9
>
> I already made such a patch as v2 and it was merged into mmc.git / fixes branch.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=e90e8da72ad694a16a4ffa6e5adae3610208f73b
What happens if the user has swiotlb=4096 on the command line (meaning
less than the default value)? Your max value will be incorrect. Could you use
swiotlb_max_segment?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-11-03 14:01 ` Geert Uytterhoeven
0 siblings, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2017-11-03 14:01 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Yoshihiro Shimoda, Konrad Rzeszutek Wilk, Linux-Renesas,
Wolfram Sang, Ulf Hansson, Linux MMC List, iommu
Hi Konrad,
On Fri, Nov 3, 2017 at 2:23 PM, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> ..snip..
>> > >
>> > > Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
>> >
>> > Did I miss that email? As in was I cc-ed?
>>
>> This was my fault. When I submitted v2 patches, I didn't include your email and iommu mailing list...
>
> No problem.
>>
>> > > https://patchwork.kernel.org/patch/10018879/
>> >
>> > Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
>> > swiotlb_max_segment? See 5584f1b1d73e9
>>
>> I already made such a patch as v2 and it was merged into mmc.git / fixes branch.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=e90e8da72ad694a16a4ffa6e5adae3610208f73b
>
> What happens if the user has swiotlb=4096 on the command line (meaning
> less than the default value)? Your max value will be incorrect. Could you use
> swiotlb_max_segment?
No, as that's the total size of the swiotlb buffer, not the maximum size of
a single segment.
Quoting an earlier part of the thread:
On Thu, Oct 19, 2017 at 1:39 PM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
>> >> iommu: Is there a better (generic) way to handle this?
>> >
>> > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
>>
>> Thanks for the pointer!
>>
>> While I agree this can be used to avoid the swiotlb buffer full issue,
>> I believe it is a suboptimal solution if the device actually uses an IOMMU.
>> It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
>> case for arm/arm64 these days.
>
> I'm afraid but I misunderstood this API's spec when I read it at first.
> After I tried to use it, I found the API cannot be used for a workaround because
> this API returns total size of swiotlb.
>
> For example:
> - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> - In this case, the maximum size per a map is 256k bytes.
> - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> into the kernel parameter on arm64.
> - In this case, the maximum size per a map is still 256k bytes because
> the swiotlb has hardcoded the size by the following code:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-11-03 14:01 ` Geert Uytterhoeven
0 siblings, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2017-11-03 14:01 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ulf Hansson, Linux MMC List, Linux-Renesas, Wolfram Sang,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Konrad Rzeszutek Wilk
Hi Konrad,
On Fri, Nov 3, 2017 at 2:23 PM, Konrad Rzeszutek Wilk <konrad-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> ..snip..
>> > >
>> > > Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
>> >
>> > Did I miss that email? As in was I cc-ed?
>>
>> This was my fault. When I submitted v2 patches, I didn't include your email and iommu mailing list...
>
> No problem.
>>
>> > > https://patchwork.kernel.org/patch/10018879/
>> >
>> > Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
>> > swiotlb_max_segment? See 5584f1b1d73e9
>>
>> I already made such a patch as v2 and it was merged into mmc.git / fixes branch.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=e90e8da72ad694a16a4ffa6e5adae3610208f73b
>
> What happens if the user has swiotlb=4096 on the command line (meaning
> less than the default value)? Your max value will be incorrect. Could you use
> swiotlb_max_segment?
No, as that's the total size of the swiotlb buffer, not the maximum size of
a single segment.
Quoting an earlier part of the thread:
On Thu, Oct 19, 2017 at 1:39 PM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
>> >> iommu: Is there a better (generic) way to handle this?
>> >
>> > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
>>
>> Thanks for the pointer!
>>
>> While I agree this can be used to avoid the swiotlb buffer full issue,
>> I believe it is a suboptimal solution if the device actually uses an IOMMU.
>> It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
>> case for arm/arm64 these days.
>
> I'm afraid but I misunderstood this API's spec when I read it at first.
> After I tried to use it, I found the API cannot be used for a workaround because
> this API returns total size of swiotlb.
>
> For example:
> - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> - In this case, the maximum size per a map is 256k bytes.
> - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> into the kernel parameter on arm64.
> - In this case, the maximum size per a map is still 256k bytes because
> the swiotlb has hardcoded the size by the following code:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-11-03 14:17 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 20+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-11-03 14:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Konrad Rzeszutek Wilk, Linux-Renesas,
Wolfram Sang, Ulf Hansson, Linux MMC List, iommu
On Fri, Nov 03, 2017 at 03:01:12PM +0100, Geert Uytterhoeven wrote:
> Hi Konrad,
>
> On Fri, Nov 3, 2017 at 2:23 PM, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > ..snip..
> >> > >
> >> > > Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
> >> >
> >> > Did I miss that email? As in was I cc-ed?
> >>
> >> This was my fault. When I submitted v2 patches, I didn't include your email and iommu mailing list...
> >
> > No problem.
> >>
> >> > > https://patchwork.kernel.org/patch/10018879/
> >> >
> >> > Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
> >> > swiotlb_max_segment? See 5584f1b1d73e9
> >>
> >> I already made such a patch as v2 and it was merged into mmc.git / fixes branch.
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=e90e8da72ad694a16a4ffa6e5adae3610208f73b
> >
> > What happens if the user has swiotlb=4096 on the command line (meaning
> > less than the default value)? Your max value will be incorrect. Could you use
> > swiotlb_max_segment?
>
> No, as that's the total size of the swiotlb buffer, not the maximum size of
> a single segment.
Aaah, then you are all fine! Thanks for the quote!
>
> Quoting an earlier part of the thread:
>
> On Thu, Oct 19, 2017 at 1:39 PM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> >> >> iommu: Is there a better (generic) way to handle this?
> >> >
> >> > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
> >>
> >> Thanks for the pointer!
> >>
> >> While I agree this can be used to avoid the swiotlb buffer full issue,
> >> I believe it is a suboptimal solution if the device actually uses an IOMMU.
> >> It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
> >> case for arm/arm64 these days.
> >
> > I'm afraid but I misunderstood this API's spec when I read it at first.
> > After I tried to use it, I found the API cannot be used for a workaround because
> > this API returns total size of swiotlb.
> >
> > For example:
> > - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> > - In this case, the maximum size per a map is 256k bytes.
> > - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> > into the kernel parameter on arm64.
> > - In this case, the maximum size per a map is still 256k bytes because
> > the swiotlb has hardcoded the size by the following code:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
@ 2017-11-03 14:17 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 20+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-11-03 14:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Linux MMC List, Linux-Renesas, Wolfram Sang,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Konrad Rzeszutek Wilk
On Fri, Nov 03, 2017 at 03:01:12PM +0100, Geert Uytterhoeven wrote:
> Hi Konrad,
>
> On Fri, Nov 3, 2017 at 2:23 PM, Konrad Rzeszutek Wilk <konrad-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > ..snip..
> >> > >
> >> > > Anyway, I made v2 patches by using swiotlb related definitions. Would you check it?
> >> >
> >> > Did I miss that email? As in was I cc-ed?
> >>
> >> This was my fault. When I submitted v2 patches, I didn't include your email and iommu mailing list...
> >
> > No problem.
> >>
> >> > > https://patchwork.kernel.org/patch/10018879/
> >> >
> >> > Why not use IO_TLB_SEGSIZE << IO_TLB_SHIFT or alternatively
> >> > swiotlb_max_segment? See 5584f1b1d73e9
> >>
> >> I already made such a patch as v2 and it was merged into mmc.git / fixes branch.
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=e90e8da72ad694a16a4ffa6e5adae3610208f73b
> >
> > What happens if the user has swiotlb=4096 on the command line (meaning
> > less than the default value)? Your max value will be incorrect. Could you use
> > swiotlb_max_segment?
>
> No, as that's the total size of the swiotlb buffer, not the maximum size of
> a single segment.
Aaah, then you are all fine! Thanks for the quote!
>
> Quoting an earlier part of the thread:
>
> On Thu, Oct 19, 2017 at 1:39 PM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> >> >> iommu: Is there a better (generic) way to handle this?
> >> >
> >> > Yes. See 7453c549f5f6485c0d79cad7844870dcc7d1b34d, aka swiotlb_max_segment
> >>
> >> Thanks for the pointer!
> >>
> >> While I agree this can be used to avoid the swiotlb buffer full issue,
> >> I believe it is a suboptimal solution if the device actually uses an IOMMU.
> >> It limits the mapping size if CONFIG_SWIOTLB=y, which is always the
> >> case for arm/arm64 these days.
> >
> > I'm afraid but I misunderstood this API's spec when I read it at first.
> > After I tried to use it, I found the API cannot be used for a workaround because
> > this API returns total size of swiotlb.
> >
> > For example:
> > - The swiotlb_max_segment() returns 64M bytes from the API when a default setting.
> > - In this case, the maximum size per a map is 256k bytes.
> > - The swiotlb_max_segment() returns 128M bytes from the API when I added swiotlb=65536
> > into the kernel parameter on arm64.
> > - In this case, the maximum size per a map is still 256k bytes because
> > the swiotlb has hardcoded the size by the following code:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/swiotlb.c?h=v4.14-rc5#n254
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2017-11-03 14:18 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-17 7:30 [PATCH 0/2] mmc: renesas_sdhi: bugfixes for v4.14 Yoshihiro Shimoda
2017-10-17 7:30 ` [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full Yoshihiro Shimoda
2017-10-17 8:02 ` Geert Uytterhoeven
2017-10-17 8:02 ` Geert Uytterhoeven
2017-10-19 0:24 ` Konrad Rzeszutek Wilk
2017-10-19 0:24 ` Konrad Rzeszutek Wilk
2017-10-19 8:34 ` Geert Uytterhoeven
2017-10-19 8:34 ` Geert Uytterhoeven
2017-10-19 11:39 ` Yoshihiro Shimoda
2017-10-20 3:18 ` Yoshihiro Shimoda
2017-11-01 13:26 ` Konrad Rzeszutek Wilk
2017-11-02 4:10 ` Yoshihiro Shimoda
2017-11-02 4:10 ` Yoshihiro Shimoda
2017-11-03 13:23 ` Konrad Rzeszutek Wilk
2017-11-03 14:01 ` Geert Uytterhoeven
2017-11-03 14:01 ` Geert Uytterhoeven
2017-11-03 14:17 ` Konrad Rzeszutek Wilk
2017-11-03 14:17 ` Konrad Rzeszutek Wilk
2017-10-17 7:30 ` [PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c Yoshihiro Shimoda
2017-10-17 8:11 ` Geert Uytterhoeven
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.