[1/2] mmc: renesas_sdhi: fix swiotlb buffer is full
diff mbox

Message ID 1508225421-25405-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
State New
Headers show

Commit Message

Yoshihiro Shimoda Oct. 17, 2017, 7:30 a.m. UTC
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(-)

Comments

Geert Uytterhoeven Oct. 17, 2017, 8:02 a.m. UTC | #1
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
Konrad Rzeszutek Wilk Oct. 19, 2017, 12:24 a.m. UTC | #2
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
Geert Uytterhoeven Oct. 19, 2017, 8:34 a.m. UTC | #3
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
Yoshihiro Shimoda Oct. 19, 2017, 11:39 a.m. UTC | #4
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
Yoshihiro Shimoda Oct. 20, 2017, 3:18 a.m. UTC | #5
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
Konrad Rzeszutek Wilk Nov. 1, 2017, 1:26 p.m. UTC | #6
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
Yoshihiro Shimoda Nov. 2, 2017, 4:10 a.m. UTC | #7
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
Konrad Rzeszutek Wilk Nov. 3, 2017, 1:23 p.m. UTC | #8
..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
Geert Uytterhoeven Nov. 3, 2017, 2:01 p.m. UTC | #9
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
Konrad Rzeszutek Wilk Nov. 3, 2017, 2:17 p.m. UTC | #10
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

Patch
diff mbox

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,
 };