All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: shawn.lin@rock-chips.com, jh80.chung@samsung.com,
	ulf.hansson@linaro.org, Vineet.Gupta1@synopsys.com,
	Wei Xu <xuwei5@hisilicon.com>,
	Joachim Eastwood <manabian@gmail.com>,
	Alexey Brodkin <abrodkin@synopsys.com>,
	Kukjin Kim <kgene@kernel.org>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Russell King <linux@arm.linux.org.uk>,
	Zhangfei Gao <zhangfei.gao@linaro.org>,
	Jun Nie <jun.nie@linaro.org>, Ralf Baechle <ralf@linux-mips.org>,
	Govindraj Raja <govindraj.raja@imgtec.com>,
	Arnd Bergmann <arnd@arndb.de>,
	dianders@chromium.org, linux-samsung-soc@vger.kernel.org,
	linux-mips@linux-mips.org, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v5 1/9] mmc: dw_mmc: Add external dma interface support
Date: Mon, 17 Aug 2015 09:11:07 +0800	[thread overview]
Message-ID: <55D134AB.80403@rock-chips.com> (raw)
In-Reply-To: <1522710.BT6Gc0L6oH@diego>

在 2015/8/15 6:13, Heiko Stübner 写道:
> Hi Shawn,
>
> Am Freitag, 14. August 2015, 16:34:35 schrieb Shawn Lin:
>> DesignWare MMC Controller can supports two types of DMA
>> mode: external dma and internal dma. We get a RK312x platform
>> integrated dw_mmc and ARM pl330 dma controller. This patch add
>> edmac ops to support these platforms. I've tested it on RK312x
>> platform with edmac mode and RK3288 platform with idmac mode.
>>
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> judging by your "from", I guess you're running this on some older Rockchip soc
> without the idma? Because I tried testing this on a Radxa Rock, but only got
> failures, from the start (failed to read card status register). In PIO mode
> everything works again.
>
>
> I guess I overlooked just some tiny detail, but to me the dma channel ids seem
> correct after all. Maybe you have any hints what I'm doing wrong?
>

Thanks, HeiKo.

yes, I'm running a quite older low-end Rockchip soc w/o idma.

Hmm... from your failure to read CSR, I think generic DMA of Radxa Rock 
was not runing properly. Your dma channel ids is correct, but it 
certainly work on my platform。 I will try to find a Radxa Rock to 
re-test my patch ASAP.



> diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
> index 4497d28..92d7156 100644
> --- a/arch/arm/boot/dts/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rk3xxx.dtsi
> @@ -217,6 +217,8 @@
>                  interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>;
>                  clock-names = "biu", "ciu";
> +             dmas = <&dmac2 1>;
> +             dma-names = "rx-tx";
>                  fifo-depth = <256>;
>                  status = "disabled";
>          };
> @@ -227,6 +229,8 @@
>                  interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>;
>                  clock-names = "biu", "ciu";
> +             dmas = <&dmac2 3>;
> +             dma-names = "rx-tx";
>                  fifo-depth = <256>;
>                  status = "disabled";
>          };
> @@ -237,6 +241,8 @@
>                  interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>;
>                  clock-names = "biu", "ciu";
> +             dmas = <&dmac2 4>;
> +             dma-names = "rx-tx";
>                  fifo-depth = <256>;
>                  status = "disabled";
>          };
>
>
> [...]
>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index fcbf552..e01ead3 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2517,8 +2642,23 @@ static void dw_mci_cleanup_slot(struct dw_mci_slot
>> *slot, unsigned int id) static void dw_mci_init_dma(struct dw_mci *host)
>>   {
>>   	int addr_config;
>> +	int trans_mode;
>> +	struct device *dev = host->dev;
>> +	struct device_node *np = dev->of_node;
>> +
>> +	/* Check tansfer mode */
>> +	trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
>> +	if (trans_mode == 0) {
>> +		trans_mode = TRANS_MODE_IDMAC;
>> +	} else if (trans_mode == 1 || trans_mode == 2) {
>> +		trans_mode = TRANS_MODE_EDMAC;
>> +	} else {
>> +		trans_mode = TRANS_MODE_PIO;
>> +		goto no_dma;
>> +	}
>> +
>>   	/* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
>> -	addr_config = (mci_readl(host, HCON) >> 27) & 0x01;
>> +	addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
>>
>>   	if (addr_config == 1) {
>>   		/* host supports IDMAC in 64-bit address mode */
>
> I guess the idmac address size checking block
>
>          /* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
>          addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
>
>          if (addr_config == 1) {
>                  /* host supports IDMAC in 64-bit address mode */
>                  host->dma_64bit_address = 1;
>                  dev_info(host->dev, "IDMAC supports 64-bit address mode.\n");
>                  if (!dma_set_mask(host->dev, DMA_BIT_MASK(64)))
>                          dma_set_coherent_mask(host->dev, DMA_BIT_MASK(64));
>          } else {
>                  /* host supports IDMAC in 32-bit address mode */
>                  host->dma_64bit_address = 0;
>                  dev_info(host->dev, "IDMAC supports 32-bit address mode.\n");
>          }
>
> could either live inside the trans_mode == 0 conditional above or get its own
> if (trans_mode == 0) conditional. Either way I guess it should not talk about
> idmac when either pio or extdmac are used.
>
>
> Thanks
> Heiko
>
>
>


-- 
Shawn Lin

WARNING: multiple messages have this Message-ID (diff)
From: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	Vineet.Gupta1-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
	Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>,
	Joachim Eastwood
	<manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Alexey Brodkin <abrodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>,
	Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Krzysztof Kozlowski
	<k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Zhangfei Gao
	<zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Jun Nie <jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
	Govindraj Raja
	<govindraj.raja-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC PATCH v5 1/9] mmc: dw_mmc: Add external dma interface support
Date: Mon, 17 Aug 2015 09:11:07 +0800	[thread overview]
Message-ID: <55D134AB.80403@rock-chips.com> (raw)
In-Reply-To: <1522710.BT6Gc0L6oH@diego>

在 2015/8/15 6:13, Heiko Stübner 写道:
> Hi Shawn,
>
> Am Freitag, 14. August 2015, 16:34:35 schrieb Shawn Lin:
>> DesignWare MMC Controller can supports two types of DMA
>> mode: external dma and internal dma. We get a RK312x platform
>> integrated dw_mmc and ARM pl330 dma controller. This patch add
>> edmac ops to support these platforms. I've tested it on RK312x
>> platform with edmac mode and RK3288 platform with idmac mode.
>>
>> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> judging by your "from", I guess you're running this on some older Rockchip soc
> without the idma? Because I tried testing this on a Radxa Rock, but only got
> failures, from the start (failed to read card status register). In PIO mode
> everything works again.
>
>
> I guess I overlooked just some tiny detail, but to me the dma channel ids seem
> correct after all. Maybe you have any hints what I'm doing wrong?
>

Thanks, HeiKo.

yes, I'm running a quite older low-end Rockchip soc w/o idma.

Hmm... from your failure to read CSR, I think generic DMA of Radxa Rock 
was not runing properly. Your dma channel ids is correct, but it 
certainly work on my platform。 I will try to find a Radxa Rock to 
re-test my patch ASAP.



> diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
> index 4497d28..92d7156 100644
> --- a/arch/arm/boot/dts/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rk3xxx.dtsi
> @@ -217,6 +217,8 @@
>                  interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>;
>                  clock-names = "biu", "ciu";
> +             dmas = <&dmac2 1>;
> +             dma-names = "rx-tx";
>                  fifo-depth = <256>;
>                  status = "disabled";
>          };
> @@ -227,6 +229,8 @@
>                  interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>;
>                  clock-names = "biu", "ciu";
> +             dmas = <&dmac2 3>;
> +             dma-names = "rx-tx";
>                  fifo-depth = <256>;
>                  status = "disabled";
>          };
> @@ -237,6 +241,8 @@
>                  interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>;
>                  clock-names = "biu", "ciu";
> +             dmas = <&dmac2 4>;
> +             dma-names = "rx-tx";
>                  fifo-depth = <256>;
>                  status = "disabled";
>          };
>
>
> [...]
>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index fcbf552..e01ead3 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2517,8 +2642,23 @@ static void dw_mci_cleanup_slot(struct dw_mci_slot
>> *slot, unsigned int id) static void dw_mci_init_dma(struct dw_mci *host)
>>   {
>>   	int addr_config;
>> +	int trans_mode;
>> +	struct device *dev = host->dev;
>> +	struct device_node *np = dev->of_node;
>> +
>> +	/* Check tansfer mode */
>> +	trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
>> +	if (trans_mode == 0) {
>> +		trans_mode = TRANS_MODE_IDMAC;
>> +	} else if (trans_mode == 1 || trans_mode == 2) {
>> +		trans_mode = TRANS_MODE_EDMAC;
>> +	} else {
>> +		trans_mode = TRANS_MODE_PIO;
>> +		goto no_dma;
>> +	}
>> +
>>   	/* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
>> -	addr_config = (mci_readl(host, HCON) >> 27) & 0x01;
>> +	addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
>>
>>   	if (addr_config == 1) {
>>   		/* host supports IDMAC in 64-bit address mode */
>
> I guess the idmac address size checking block
>
>          /* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
>          addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
>
>          if (addr_config == 1) {
>                  /* host supports IDMAC in 64-bit address mode */
>                  host->dma_64bit_address = 1;
>                  dev_info(host->dev, "IDMAC supports 64-bit address mode.\n");
>                  if (!dma_set_mask(host->dev, DMA_BIT_MASK(64)))
>                          dma_set_coherent_mask(host->dev, DMA_BIT_MASK(64));
>          } else {
>                  /* host supports IDMAC in 32-bit address mode */
>                  host->dma_64bit_address = 0;
>                  dev_info(host->dev, "IDMAC supports 32-bit address mode.\n");
>          }
>
> could either live inside the trans_mode == 0 conditional above or get its own
> if (trans_mode == 0) conditional. Either way I guess it should not talk about
> idmac when either pio or extdmac are used.
>
>
> Thanks
> Heiko
>
>
>


-- 
Shawn Lin

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-08-17  1:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14  8:33 [RFC PATCH v5 0/9] Add external dma support for Synopsys MSHC Shawn Lin
2015-08-14  8:33 ` Shawn Lin
2015-08-14  8:34 ` [RFC PATCH v5 1/9] mmc: dw_mmc: Add external dma interface support Shawn Lin
2015-08-14  8:34   ` Shawn Lin
2015-08-14 22:13   ` Heiko Stübner
2015-08-14 22:13     ` Heiko Stübner
2015-08-16 21:10     ` Doug Anderson
2015-08-16 21:10       ` Doug Anderson
2015-08-16 21:10       ` Doug Anderson
2015-08-17  6:27       ` Shawn Lin
2015-08-17  6:27         ` Shawn Lin
2015-08-17  1:11     ` Shawn Lin [this message]
2015-08-17  1:11       ` Shawn Lin
2015-08-14  8:34 ` [RFC PATCH v5 2/9] Documentation: synopsys-dw-mshc: add bindings for idmac and edmac Shawn Lin
2015-08-14  8:34   ` Shawn Lin
2015-08-14  8:35 ` [RFC PATCH v5 3/9] mips: pistachio_defconfig: remove CONFIG_MMC_DW_IDMAC Shawn Lin
2015-08-14  8:35   ` Shawn Lin
2015-08-14  8:35 ` [RFC PATCH v5 4/9] arc: axs10x_defconfig: " Shawn Lin
2015-08-14  8:35   ` Shawn Lin
2015-08-14  8:35   ` Shawn Lin
2015-08-14  8:35 ` [RFC PATCH v5 5/9] arm: exynos_defconfig: " Shawn Lin
2015-08-14  8:35   ` Shawn Lin
2015-08-14  8:35 ` [RFC PATCH v5 6/9] arm: hisi_defconfig: " Shawn Lin
2015-08-14  8:35   ` Shawn Lin
2015-08-14  8:36 ` [RFC PATCH v5 7/9] arm: lpc18xx_defconfig: " Shawn Lin
2015-08-14  8:36   ` Shawn Lin
2015-08-14  8:36 ` [RFC PATCH v5 8/9] arm: multi_v7_defconfig: " Shawn Lin
2015-08-14  8:36   ` Shawn Lin
2015-08-14  8:36 ` [RFC PATCH v5 9/9] arm: zx_defconfig: " Shawn Lin

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=55D134AB.80403@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=abrodkin@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=govindraj.raja@imgtec.com \
    --cc=heiko@sntech.de \
    --cc=jh80.chung@samsung.com \
    --cc=jun.nie@linaro.org \
    --cc=k.kozlowski@samsung.com \
    --cc=kgene@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=manabian@gmail.com \
    --cc=ralf@linux-mips.org \
    --cc=ulf.hansson@linaro.org \
    --cc=xuwei5@hisilicon.com \
    --cc=zhangfei.gao@linaro.org \
    /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.