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 Konrad,

On Thu, Oct 19, 2017 at 2:24 AM, Konrad Rzeszutek Wilk
<konrad@xxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxx>
>> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx>
>>
>> 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@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



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux