All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: "linux-renesas-soc@vger.kernel.org"  <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH RFC 4/4] mmc: host: renesas_sdhi_sys_dmac: Set dma_buswidth value to 32 byte
Date: Mon, 2 Dec 2019 09:54:48 +0100	[thread overview]
Message-ID: <20191202085448.GD1266@kunai> (raw)
In-Reply-To: <TYAPR01MB45448366F6EB1F581CD399F7D8430@TYAPR01MB4544.jpnprd01.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

Hi Shimoda-san,

> > 1) can't we set dma_priv->dma_buswidth at runtime when we know what the
> > card is capable of? Either DMA_SLAVE_BUSWIDTH_32_BYTES or
> > DMA_SLAVE_BUSWIDTH_4_BYTES? Then we don't need to fallback to PIO.
> > AFAIS, we only Gen2 sets .dma_buswidth in of_data, so we could even
> > remove it from of_data entirely?
> 
> As I replied to Ulrich-san on other email thread, for now, rcar-dmac has a limitation
> on dmaengine_slave_config(), we should not call it at runtime. But, I don't think
> any sd card have such a limitation. In other words, if rcar-dmac doesn't have
> the limitation, I think we can change the buswidth at runtime and then we can
> remove the .dma_buswidth from of_data.

So, that I understand correctly: The DMAC limitation is because of the
driver and not because of the HW? If so, is it hard/planned to be fixed?

> I also grepped in drivers/dma, and all dmaengine drivers except Renesas related
> SoCs don't support DMA_SLAVE_BUSWIDTH_32_BYTES. So, I think no driver uses
> the 32 bytes on mmc/hosts :)

Wow, we are bleeding edge with this? :)

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-12-02  8:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22  6:13 [PATCH RFC 0/4] mmc: host: renesas_sdhi_sys_dmac: change dma_buswidth Yoshihiro Shimoda
2019-11-22  6:13 ` [PATCH RFC 1/4] mmc: host: renesas_sdhi_sys_dmac: Use dma_buswidth instead of hardcoded value Yoshihiro Shimoda
2019-11-26 10:45   ` Ulrich Hecht
2019-11-22  6:13 ` [PATCH RFC 2/4] mmc: host: renesas_sdhi_sys_dmac: Do not fall back to PIO Yoshihiro Shimoda
2019-11-26 10:45   ` Ulrich Hecht
2019-11-22  6:13 ` [PATCH RFC 3/4] mmc: host: renesas_sdhi_sys_dmac: add DMACR setting Yoshihiro Shimoda
2019-11-26 10:46   ` Ulrich Hecht
2019-12-02  8:19     ` Yoshihiro Shimoda
2019-11-22  6:13 ` [PATCH RFC 4/4] mmc: host: renesas_sdhi_sys_dmac: Set dma_buswidth value to 32 byte Yoshihiro Shimoda
2019-11-26 10:46   ` Ulrich Hecht
2019-11-28 21:07   ` Wolfram Sang
2019-12-02  8:38     ` Yoshihiro Shimoda
2019-12-02  8:54       ` Wolfram Sang [this message]
2019-11-26 10:45 ` [PATCH RFC 0/4] mmc: host: renesas_sdhi_sys_dmac: change dma_buswidth Ulrich Hecht
2019-12-02  8:09   ` Yoshihiro Shimoda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191202085448.GD1266@kunai \
    --to=wsa@the-dreams.de \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.