RE: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx
> >
> > 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
��.n��������+%������w��{.n�����{��i��)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux