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
> <kon...@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...@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.be...@de.bosch.com>
> >> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@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 --
> ge...@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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
