| Message ID | 1508225421-25405-2-git-send-email-yoshihiro.shimoda.uh@renesas.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
..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? -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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, };
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(-)